Привет, Хабр! Сегодня я расскажу вам, как использование практик DevOps не только не помогает, но и вредит проекту.
DevOps был создан для того, чтобы команды разработки и поддержки могли работать эффективно и слаженно.
Но иногда использование его наработок может привести к настоящим провалам.
Зачем и кому нужен DevOps
Сначала немного истории.Самый первый компьютер в мире появился в 1936 году, его создал Алан Тьюринг.
Тогда был ровно один компьютер и ровно один программист. Вычислительные машины существовали и до этого, но Алан Тьюринг сконструировал первый электронный компьютер, похожий на компьютер в том смысле, в котором мы его понимаем, и написал первую строку кода, которую мы распознаем как код. 
В течение следующих 30 лет количество компьютеров и программистов увеличится с нескольких до десятков и сотен тысяч.
После войны программисты стали людьми, которые проектировали, собирали и ремонтировали компьютеры.
В 1950-е годы к ним присоединились ученые, математики и инженеры.
Именно в этот момент, примерно в 1953 году, появился первый в мире язык программирования Фортран.
И тут появилась то, с чем пытается бороться DevOps. В 1960-е годы компьютеры стали дешевыми и компактными, а программисты стали не учёными и математиками, а опытными сотрудниками без специального образования, которым руководство могло доверить управление огромными, дорогими машинами.
В 1970-е годы программистов было уже более миллиона, а потребность в них росла и росла.
К тому времени университеты начали выпускать первых специалистов – молодых, неопытных ребят. И именно в этот момент что-то пошло не так.
До 70-х годов программисты были дисциплинированными профессионалами.
Им не нужен был менеджмент – они умели распоряжаться своим временем, как работать друг с другом, как общаться с разными отделами.
Они понимали, что такое бизнес, сроки, обещания, графики.
Они знали, над чем работать сейчас, а что оставить на потом.
Это были высококвалифицированные, опытные специалисты.
Они творили чудеса: придумали операционную систему IBM 360 Virtual Memory, отправили устройство на Луну и изобрели структурное, функциональное и объектно-ориентированное программирование.
Придумали Фортран, Кобол, Алгол, Лисп, Юникс.
Оказывается, они даже работали в чем-то, напоминающем современный Agile. После 70-х программистами стали молодые люди, недавно окончившие вузы.
Чаще всего — компьютерщики, интересующиеся компьютерами.
Этим неопытным ребятам, которые не понимали необходимости графика, ответственности и дисциплины, требовалось управление сверху, чтобы гарантировать, что компании получают от них то, что хотят. Затем родился Waterfall, который руководил программистами еще десятилетия.
Это связано с тем, что вокруг не хватало учителей, которые могли бы объяснить, как работать, и такая ситуация сохраняется до сих пор.
Проработав 20 лет и став опытными специалистами, бывшие молодые ребята поняли, что в отрасли что-то не так, что программистов превращают в простых рабочих, не разбирающихся в бизнесе и не обладающих критическим мышлением.
Они просто выполняют свои задачи и делают то, что им говорит руководство.
Инженеров, привыкших быть в роли интеллектуальных творцов, такой подход уже не устраивает.
Agile и что с ним случилось
Несколько таких ребят собрались в 1995 году и написали Agile-манифест, в котором изначально было всего четыре пункта.Основная цель заключалась в преодолении разрыва между бизнесом и программистами.
Они хотели донести: мы профессионалы, мы должны быть ближе к делу, нам не нужны ритуалы Водопада.
Это пункты: 
И вот Agile, зародившийся в инженерной среде для помощи тем же инженерам, превратился во что-то другое.
Теперь это 90% управленческой истории.
Если вы посмотрите темы докладов любых Agile-конференций, вы не найдете в них технических тем — только управленческие рассказы о том, как руководить командой и тому подобное.
Почему мы как отрасль потерпели неудачу и не смогли внедрить Agile? Почему наши менеджеры делают это вместо нас? Возможно, мы были недостаточно зрелыми, чтобы усвоить набор практик и дисциплин, которые нам предлагали.
Техническая экспертиза ушла в тень, на смену ей пришла сфера управленческой экспертизы: ритуалы, практики, процессы, которые можно контролировать.
Как инженерное движение, Agile потерпел неудачу.
DevOps и что с ним случилось
Проходит еще несколько лет, и в 2008-2009 годах зарождается DevOps-культура — она стала идеей, движением инженеров, целью которых было устранение разрыва между системными операторами и программистами при создании и обновлении программных продуктов.Это методология, которая эффективно решает проблемы взаимодействия команд разработки и эксплуатации за счет автоматизации и интеграции усилий обеих сторон.
На практике участников больше: задействованы специалисты по безопасности, специалисты по платформам и инфраструктуре, нормативным требованиям и другие.
Это движение было создано теми, кто пострадал, вырос в профессионалов и прошел долгий путь.
Что сейчас происходит с DevOps? К сожалению, то же самое произошло и с Agile: практики и инструменты взяли верх.
Появились DevOps-инженеры, DevOps-практики начали продавать и покупать и пытались внедрить его повсеместно.
И похоже мы с вами проваливаем движение, в очередной раз натыкаясь на те же грабли.
Мы снова не можем освоить ту дисциплину, которая нам предлагается.
Мы снова скатываемся к практикам, понятным прежде всего менеджерам.
DevOps стал галочкой в контрактах, в презентациях проектов клиентам.
Посмотрите на сегодняшних DevOps-инженеров: они берут то, что сделали программисты, и критикуют это вместо того, чтобы работать вместе над созданием качественных продуктов.
Я вам сейчас расскажу, к чему это может привести.
Надеюсь, на примерах неудач мы сможем что-то понять.
провалы
А теперь пришло время интересных историй.
Инфраструктура как код
Первая история об инфраструктуре как коде.Данный : У нас новый проект, мы переезжаем в облако.
Мы делаем Инфраструктуру как Код и в 80% случаев используем для этого Terraform. Действия: Мы взяли в руки Terraform, посмотрели документацию и пару видео и начали делать.
Все началось хорошо.
Проекту нужна была одна среда для программиста Васи — она состояла из трёх виртуальных машин и сетей между ними.
Все это легко умещается в один файл Terraform. Потом пришел программист Витя, которому нужна была среда, а также общая среда, в которой постоянно была бы развернута мастер-ветка нашего приложения.
Что сделали гуру Terraform? Мы взяли оригинальный файл и скопировали его, поменяли внутри названия: все работает, все довольны.
Проект растёт — появляются программист Вова и команда QA, которым нужна отдельная среда.
Среда усложняется: в ней появляются хранилища, балансировщики нагрузки и другие нетривиальные вещи.
Управлять всем этим становится неудобно.
К счастью, команда вовремя прочитала о модулях Terraform, все переделала в модули и создала все среды, используя общие модули и удалив 80% копипаста.
Все здорово, все замечательно.
Пока.
Возникает момент, когда вам необходимо срочно клонировать виртуальную машину из среды QA в среду Пети, чтобы срочно исправить дефект. Потому что мы там что-то взяли на себя.
Ребята, которые делают Terraform, разводят руками, говорят, что не знают, как клонировать виртуальную машину через Terraform, и берут пару дней на раздумья.
Но у нас нет этих двух дней.
Старший программист бьется, чтобы забрать пароль администратора из облака, за 30 секунд получает себе клон виртуальной машины и вперед. И в этот момент в команде возникает некое озарение: они понимают, что Terraform на самом деле не нужен.
В сложных случаях, когда команда Terraform не на связи, можно что-то сделать самостоятельно.
Последствия: История с дырками возникает, когда кто-то сделал что-то не так с руками.
В какой-то момент наша производственная среда становится такой же дырявой.
У нас есть модуль, его пытались привести к готовому виду, развернули, но что-то не получилось.
Какой-то ответственный человек, который затеял это производство, зашёл в облако, поменял настройки, что-то добавил и, не дай Бог, связал это с какой-то проброской в среду QA. И у нас было такое производство.
Он проработал достаточно долго, проект принес деньги, и все остались довольны.
Пока не пришел новый клиент. Он говорит: «У вас такой классный продукт. Я уже приобрел подписку, но меня не устраивает время ответа.
Можете ли вы построить нам инфраструктуру в Европе? Мне очень нужно".
Что мы наделали? Мы взяли Terraform, изменили одну переменную, накатили на соседний регион, установили среду через наш суперавтоматизированный пайплайн, но это не сработало.
Стали разбираться, почему не работает, сравнили и всё стало понятнее.
Никто не знал, что один младший тестировщик имел облачный пароль и что-то в нем менял.
В конце концов : Конечно, окружение делалось в Европе, но спустя долгое время и без Терраформа.
Мы взяли CloudFormation, загрузили в него инфраструктуру, немного подправили файлы вручную и развернули в соседний регион.
Еще раз: мы взяли Terraform и вместо того, чтобы сделать что-то хорошее для проекта, сделали что-то плохое.
Этот Терраформ мешал всем, потому что мешал им делать то, что им нужно было.
Плюс мы потратили много времени, идя в никуда.
Возможное решение: Можно ли было что-то сделать по-другому? Конечно.
Прежде чем принимать какое-либо средство, необходимо понять, какие проблемы оно решает. Terraform — это код, и его нужно было запускать как код для взрослых.
Должны были быть пул-реквесты, CI, контроль, каждую ночь нужно было проверять соответствие облака коду Terraform. Нужно было ввести правила работы с Terraform и либо рассказывать о них и прививать, либо наводить дисциплину в команде.
Самое главное, что Terraform — не единственный инструмент «Инфраструктура как код», который вам следует использовать.
Почему у ребят не было политики? Почему они допустили ситуации, когда кто-то мог войти в облако без его ведома? Инфраструктура как код должна включать не только ресурсы, но и политики, которые вы устанавливаете.
Да, вы не сможете выстроить оборону со своими политиками, как в Форт-Ноксе.
Но можно поставить высокий деревянный забор, через который будет сложно перепрыгнуть.
И если кто-то попробует, вы об этом узнаете.
Кубернетес
Следующая история про Kubernetes. Данный: Нам нужно перенести устаревшее приложение в облако.Команда изучила Legacy, пообщалась с его архитекторами, программистами, которые его поддерживают: приложение работает на устаревшем оборудовании, его необходимо перевести на x86 и Linux. Оказалось, что это клиент-серверное веб-приложение, разбитое на сервисы, и они настолько малы, что их можно назвать микросервисами.
Плюс он использует компонент, который масштабирует эти сервисы в зависимости от нагрузки.
Любой здравомыслящий DevOps-инженер скажет вам, что это нужно развернуть в Kubernetes. Действия: В ходе реализации проекта мы столкнулись с очень серьезными проблемами.
Сервисы были очень маленькими, занимали менее 5 мегабайт. Но для работы каждому требовалось 6 ГБ зависимостей времени выполнения.
Эти 6 гигов собирались очень долго: примерно четыре-пять часов на чистую сборку (в зависимости от фазы луны).
В результате получились огромные, гигантские изображения, которые нужно было где-то хранить.
Время сборки стало очень долгим, и возникли огромные проблемы с масштабируемостью.
Представьте: у вас есть 10 образов по 6 ГБ каждый, и Kubernetes в облаке добавляет в кластер еще один сервер, чтобы выкатить туда дополнительную реплику сервиса.
А потом туда начинают скачиваться все изображения еще минут пять, а пользователи сидят и ждут. Последствия: Нужно было добиться того, чтобы все образы сохранялись на всех узлах, чтобы понять, как иметь определенное количество горячих узлов без рабочей нагрузки.
И вообще, полностью зафиксировать количество реплик сервиса, чтобы приложение поддерживало максимальную нагрузку на продакшен, и всё.
Пришлось отказаться от масштабирования по облачной модели pay-as-you-go и где-то хранить огромные изображения.
Мы добавили себе огромное количество головной боли.
Позже выяснилось, что наше приложение основано на TCP/IP и мы потеряли половину тех плюшек, которые Kubernetes предоставляет нам просто из коробки.
Мы не можем осуществлять маршрутизацию на основе URL-адресов, мы не можем размещать две версии приложения рядом по разным ссылкам.
Мы не можем делать маршрутизацию по заголовкам, не можем допускать тестировщиков в соседнюю версию сервиса.
Мы не можем позволить себе быстро и легко сделать blue/green-деплой илиrollout-деплой в Kubernetes, потому что большинство готовых фишек для этого рассчитаны на http-трафик.
В конце концов: Получили кластер из 10 дорогих узлов, много проводки вокруг, много необоснованных расходов.
Никто не доволен, и мы не можем быстро обновить приложение.
Возможное решение: Можно ли было избежать этой ситуации? Да, ты можешь.
Пришлось выбросить Kubernetes, забыть о контейнерах в том виде, в котором он их использует, прибегнуть к другой технологии изоляции процессов — некоему серверу приложений — и просто развернуть приложение в Linux. И вместо десяти нод с кучей проводок мы получили бы три сервера и один балансировщик нагрузки.
Это глупое, но работающее и дешевое решение проблемы.
Опять же, вам нужно понимать, что такое Kubernetes и для каких приложений он вам подходит. Надо разобраться в деталях: что это за приложение? как это будет работать? кто это напишет? Это цена опыта.
Ребята, которые работают и работали над этим проектом, в следующий раз не будут сразу бросаться в Kubernetes. Рекомендую вам почитать о нем побольше.
Если кто-то еще не работает и только прошел курс обучения или планирует использовать это программное обеспечение в новом проекте, пожалуйста, поймите, для каких приложений оно подходит и какие проблемы решает. Возможно, у вас вообще нет таких проблем.
CI/CD/CT
Последняя история про CI/CD/CT. Данный: Есть существующий проект Big Data, который написали молодые ребята без поддержки преподавателей.Никакой системы контроля версий они не использовали — приложение просто лежит в файлах, ведрах в облаке.
Когда им нужно проверить какую-то гипотезу, они делают полную копию приложения, меняют там код и начинают обработку с этой копии.
Если все сработало, гипотеза удачна, то они сливают ее обратно в основную копию, и на это слияние у них уходит два дня, потому что многие хотят слиться.
Кроме того, они выбрали технологию, о которой все на слуху, Spark, вместо той, которая могла бы поддерживать требования.
И в итоге все это работает шесть часов вместо положенных бизнесу 20 минут. Действия: наступает момент, когда нужно показать проект клиенту — достаточно серьезной технологической компании, которая распознает этот бардак и останется недовольной.
Затем к проекту присоединяются еще люди — так называемая «Команда А».
У них есть два месяца, чтобы все взять и привести к тому виду, который привыкли видеть клиенты: внедрить контроль версий, исправить процессы, сделать CI/CD/CT и исправить код, чтобы аптайм был оптимальным.
Код быстро поправили, программисты знают свое дело.
Последствия: А вот с CI случилась очень интересная история.
Мы внедрили Git, затем начали заниматься непрерывной интеграцией.
Как правило, непрерывная интеграция не выполняется на основе транка, а обычно выполняется на основе запросов на включение: запрос на включение получает проверки перед слиянием, и после прохождения всех этапов проверки код мержится в основную ветку.
Когда мы приступили к этому этапу, оказалось, что в проекте есть ровно один тест, который занимает те же шесть часов, а других тестов нет, и сделать их невозможно.
Приложение было быстро оптимизировано, время выполнения сократилось до четырёх часов, что, конечно, тоже немало для пулл-реквеста.
Самое главное, что тесты почти сразу начали проваливаться не из-за изменений кода, а по независимым причинам.
Мы пробовали задействовать QA, фиксировать входящий набор данных и многое другое — стабилизировать тест нам так и не удалось.
В общем, автоматически составить критерии прохождения теста было невозможно.
И вот у нас пул-реквесты висят четыре часа, а желаемого результата нет. Тогда мы решили вообще отказаться от тестирования пулл-реквестов и хотя бы подключить туда линтер.
Включили - показало, куда обратить внимание, и эти баги исправили.
Но в какой-то момент линтер просто сломался.
Как это произошло: внесли изменение, в результате чего у линтера внутри появилась бесконечная рекурсия, и он просто выпал с километровым stacktrace. Мы попытались это исправить, отвлекая разработчиков.
Не смог это исправить.
В результате линтер все равно был красный.
Что случилось? Никто не удосужился взглянуть на CI, потому что он всегда был красным.
Помимо этой трассировки стека, провалившей наши проверки, часто возникали реальные дефекты, которые впоследствии переросли в производственные дефекты, но этого никто не замечал, хотя линтер их находил.
Тогда не отключили, думали починим, но мы так и не сделали.
В результате список замороженных пул-реквестов выглядел ужасно — все сборки проваливались.
Затем речь шла о выкатке кода в среду.
Развертывание приложения оказалось крайне тривиальным — достаточно перенести файлы из Git в облако, даже не нужно было делать никакой настройки.
Конфигурация содержалась в данных.
Автоматизировать такой Continuous Deployment очень легко, что и было сделано.
Непрерывное тестирование сначала появилось в виде пул-реквестов, а затем стало ночным.
То же самое было и с тестированием внутри пул-реквестов.
Невозможно было просто запустить тесты и потом понять, успешны они или нет. Во-первых, они занимали много времени, во-вторых, результаты приходилось анализировать вручную.
В конце концов: Мы проделали большую работу, но не добились положительных результатов.
Наоборот: мы мешали работать другим людям.
Возможное решение: Узнайте, что такое CI и для чего она нужна, прежде чем делать непрерывную интеграцию под копирку.
Помните, как мы обычно делаем CI? У нас подготовлены пайплайны, появляется новый проект — мы берём эти пайплайны и адаптируем их, говорим: я DevOps-инженер, я свою работу сделал, пользуйтесь.
В данной ситуации этого делать не стоило, потому что не было проблемы, которую решает такое CI. Были и другие проблемы.
Что требовалось в этом проекте? Найдите места, где команде действительно нужна помощь, даже если вам прямо говорят: идите и делайте CI. В этом проекте отсутствовала система для запуска DEV в изолированной среде.
Разработчикам нужен был скрипт, который бы всё подготовил, скопировал данные и запустил приложение, чтобы запуск не мешал запуску другого разработчика.
Желательно, чтобы эта функция запускалась с ноутбука и не нужно было куда-то коммитить код, чтобы она там запускалась (а потом крашилась).
В итоге мы это сделали, выдернули куски из нашего под-КИ, и работа началась.
Но то, что мы в итоге сделали, и то, что нас просили сделать изначально, — это разные вещи.
Как не потерпеть неудачу
Как предотвратить подобные сбои? Кто-то может сказать: это не неудачи, а настоящая рабочая атмосфера.Решайте сами, но мне не нравится такая атмосфера.
Как показала практика, самый простой и верный шаг – тщательное изучение предлагаемых решений на берегу.
Необходимо понимать функционал инструментов со всех сторон, понимать их использование на конкретном проекте.
Возможно, то, что говорит нам опыт или статистика приложений, неверно.
Воспитывайте дисциплину в команде, обсуждайте правила игры.
Оглянитесь вокруг, поговорите с другими людьми, попробуйте поработать вместе в рамках проекта с разработчиками и позаботьтесь о том, чтобы все хорошо провели время.
Всего наилучшего! Теги: #программирование #Управление разработкой #кейсы #DevOps #agile
-
Государственные Тесты Глазами Программиста
19 Oct, 24 -
Cocoaheads Россия. Прямая Трансляция
19 Oct, 24 -
Простой Алгоритм Метапоиска На Python
19 Oct, 24 -
Что Быстрее While (True) Или For (;;)?
19 Oct, 24
