Последние несколько лет мы при каждом удобном случае снова и снова обсуждаем, что же такое DevOps. Это уже порядком надоело, но раз всё еще происходит, значит есть проблема — проблема взаимодействия бизнеса и инженеров.
Я часто вижу, как люди, пришедшие к применению DevOps из разных сфер, говорят на разных языках и понимают под словом DevOps совершенно разное. В итоге в какой-то момент времени оказывается, что участники проекта по трансформации абсолютно не понимают и друг друга, и зачем нужен весь этот DevOps тоже.
Я не хочу рассуждать о том, что такое DevOps и какое его понимание более правильное. Мне интересно проследить за эволюцией процессов в IT и разобраться, что бизнес хочет получить от внедрения DevOps, что это значит для инженеров и как нам быть на одной волне.
N.B.: Материал для этой статьи лёг в основу моего выступления на DevOps Live, поэтому вместо чтения можно послушать доклад — он вполне сойдёт за подкаст.
На примере клиентов ITSumma я вижу, как изменились запросы бизнеса в последние несколько лет. Мы занимаемся сопровождением сложных информационных систем с 2008 года, и поначалу это в основном была работа по обеспечению отказоустойчивости сайтов, но теперь появились кардинально новые запросы. Раньше важнее всего было, чтобы продакшен стабильно работал, был готов к масштабированию, а в случае аварии быстро поднимался. Теперь не менее важным стало обеспечение отказоустойчивости платформ разработки и систем выкладки.
В крупных компаниях произошло смещение системы ценностей: стабильная работа develop-окружения теперь так же важна, как и надежность продакшена.
Чтобы проследить траекторию и понять, что изменилось в и где мы теперь, погрузимся ненадолго в историю разработки программного обеспечения.
Немного истории разработки
Я считаю, что есть, условно, четыре эпохи в развитии принципов разработки программного обеспечения. И что важно — на всех этапах существовала и доставка ПО. Просто в разное время эту доставку обеспечивали разные люди.
Мейнфреймы. 1960–1980-е годы
Особенности периода. Начальный этап с появления компьютеров как таковых до примерно 1985-го года характеризуется тем, что программы разрабатывают для себя. Небольшие группы разработчиков реализуют довольно ограниченную функциональность, которая отвечает нуждам и используется внутри одной компании или госструктуры. Этой ограниченной функциональностью может быть запуск людей на Луну, но всё равно сфера применения этой программы гораздо-гораздо уже, чему у современных сервисов.
Пользователи: сотрудники компании. Число пользователей программ того времени очень ограниченно: это 3 космонавта корабля «Аполлон», 20 человек, рассчитывающих государственный бюджет, 100 человек, обрабатывающих результаты переписи населения.
Дистрибуция ПО: физическая, на мейнфрейме. Пробиваются перфокарты, загружаются в ЭВМ, и минут через 10 программа готова к использованию. За доставку, по сути, отвечает человек, который пробивает перфокарты. При этом если программист допустил ошибку, то исправлять её долго: заново писать и отлаживать код, пробивать перфокарты, загружать. На всё это уйдут дни и впустую будет потрачено время многих людей — цена ошибки очень высока, возможно, катастрофа.
На этом этапе IT-бизнеса как такового еще не существует. Если посмотреть в Википедии количество компаний по производству ПО, основанных в 1975-м, то их там будет всего четыре. Правда, одна из них — Microsoft, которая тогда была очень маленькой и нишевой.
Персональные компьютеры и ООП. 1980-1990-е годы
Все начинает меняться примерно в 1985 году с массовым распространением персональных компьютеров: в 77-м началось производство Apple II, в 81-м появился IBM PC, чуть раньше стали популярны минимейнфреймы от DEC.
Особенности периода: создание программного обеспечения начинает формироваться в бизнес-направление. Это становится возможным, потому что пользователей программ стало больше и можно строить программы на продажу.
Например, в 79-м появляется электронная таблица VisiCalc, которая заменяет собой бухгалтера-калькулятора — человека, который фактически работал excel'ем. Бухгалтер заносил в большую бумажную таблицу числа и как-то по формулам их обрабатывал. Потом аналитик спрашивал, что будет, если доход в третьем квартале будет в два раза больше, и бухгалтер-калькулятор менял одно значение и снова всё пересчитывал на бумаге.
Пользователи: внешние по отношению к производителю ПО компании. VisiCalc перевернул всю индустрию компьютерного бизнеса, программа, вместо узконаправленной штуки, которая пишется для конкретного набора людей, стала массовой. Например, экономисты и аналитики стали покупать компьютеры, чтобы использовать электронные таблицы.
Поскольку пользователей стало много и программы начали продавать частным лицам, возникает вопрос: как сделать так, чтобы программа работала у такого большого количества людей, и как разрабатывать такие сложные программы.
Поскольку расширяется аудитория, то нужна и большая функциональность. Соответственно, нужно увеличивать команду разработки — это уже не десяток программистов, а 100-500 человек, которые работают над сложным программным продуктом.
Интересно, что в каждой эпохе становления IT есть несколько ключевых книг, которые в своё время вызвали переворот в . Период, когда зарождается бизнес разработки программного обеспечения и команды разработчиков растут, на мой взгляд, характеризуется двумя книгами: «Мифический человеко-месяц» и «Приёмы объектно-ориентированного проектирования. Паттерны проектирования». То есть с одной стороны появляется понимание, что невозможно, увеличив команду в 4 раза, сократить время разработки в 4 раза. А с другой — что есть решение, которое способно помочь масштабироваться.
Популярным решением проблемы роста сложности ПО становится ООП. Считается, что если взять большую программу, допустим, Microsoft Excel, и разбить на какие-то объекты, то группы разработчиков смогут работать над ними независимо. Таким образом получится масштабировать работу на отдельные элементы функциональности и ускорить разработку нашего Microsoft Excel. Причем под «ускорить», скорее всего, понимается цикл разработки в несколько лет.
Аргументация внедрения ООП звучит очень похоже на плюсы микросервисной архитектуры.
Но по сути, мы по-прежнему упаковываем программу в один пакет — exe-файл во времена повсеместного использования Microsoft DOS, а потом Windows — и поставляем пользователю.
Доставка ПО: на физических носителях. Но так как теперь это массовое производство, то доставка ПО заключается в том, чтобы: записать наш exe-шник на дискеты, наклеить на них наклейки с названием продукта, упаковать в коробки и буквально доставить пользователям в разных странах. При этом необходимо не допустить существенное количество брака, потому что если произвести дискеты где-нибудь в Америке, доставить в Россию и обнаружить, что половина из них с браком, это будут огромные издержки и мы потеряем пользователей насовсем.
Цена ошибки: пользователи вернут деньги и больше никогда не купят продукт, что может погубить весь бизнес.
Цикл разработки ПО просто потрясающе долог, этапы занимают месяцы:
- планирование — 12 месяцев;
- разработка — 24 месяца;
- тестирование — 12 месяцев;
- доставка — 12 месяцев.
Новая версия выпускается раз в несколько лет, поэтому никак нельзя допускать ошибки на этапе кодирования.
Однако главный риск связан с тем, что на протяжении всего этого длинного цикла разработки отсутствует обратная связь от пользователей.
Представьте: мы придумали новый IT-продукт, провели небольшое исследование и решили, что, возможно, эта программа понравится пользователю. Но убедиться в этом мы никак не можем! Мы можем только два года писать софт, а потом попросить бухгалтеров у себя в округе, например, в Редмонде, поставить новую версию Excel и попробовать её использовать. И это по сути все наши возможности для тестирования продукта. Поэтому не исключено, что через два года разработки окажется, что наше ПО никому не нужно.
Если же наш софт всё-таки покупают, но он имеет баги и плохо работает, то пользователи легко могут его вернуть — это еще физический товар, коробка, которую можно принести обратно в магазин. И заодно решить, что покупать ПО этого производителя больше никогда не стоит.
Agile. 2001–2008
Следующая эра начинается с распространением интернета в 2000-х.
Особенности периода: IT-бизнес переходит в интернет, но браузеры работают еще так себе.
Microsoft создаёт Internet Explorer и бесплатно поставляет его всем пользователям Windows. Интернет становится доступен огромному числу людей, но при этом браузер Microsoft целенаправленно сделан не очень пригодным для реализации динамической функциональности, чтобы защитить свои программы от конкуренции со стороны браузерных приложений и Netscape (подробнее по запросу «Война браузеров»). Поэтому интернет еще используется в основном для загрузки файлов, но этого уже достаточно, чтобы бизнес перешёл в интернет.
Доставка ПО: дистрибутивы становится возможно распространять через интернет.
Дистрибуция ПО через интернет позволяет гораздо чаще — раз в несколько месяцев — выпускать обновления и новые версии. Больше не обязательно записывать ПО на дискеты и диски — пользователи могут скачать обновления из интернета, а разработчики могут допускать больше ошибок.
Цена ошибки: риск для бизнеса уже не так велик, потому что пользователь может получить обновление и продолжить пользоваться продуктом.
Где-то в это время зарождается Agile и выходят книги о гибкой разработке и экстремальном программировании, которые и для современного IT-менеджмента являются классической основой, например: «Extreme Programming Explained: Embrace Change», «Refactoring. Improving the Design of Existing Code», «Test Driven Development».
Основная идея в том, что раз доставлять ПО можно через интернет, то цикл производства может быть гораздо короче, а новую версии можно выпускать каждые полгода.
Цикл разработки в начале 2000-х выглядит примерно так:
- планирование — 2 месяца;
- разработка — 6-12 месяцев;
- тестирование — 1-3 месяца;
- доставка — несколько недель.
Можно, например, больше не тестировать так тщательно. Если у 10% пользователей проявятся баги, то для них можно выпустить патч, а не тратить заранее год на то, чтобы убедиться, что наше ПО работает как надо абсолютно везде. Таким образом, можно гораздо быстрее проверять гипотезы, но быстрее тут — это по-прежнему полгода-год.
То, что можно меньше вкладываться в тестирование и детальное планирование, позволяет сократить расходы на проведение эксперимента. И слово «эксперимент» станет ключевым в следующую эпоху.
DevOps. 2009–2020
Особенности периода: устанавливаемого ПО практически не осталось, а немногое существующее обновляется через интернет. Интернет используется повсеместно, становятся популярны социальные сети и развлекательный софт, которые живут исключительно в интернете. Реализовывать сложную динамическую функциональность интерфейсов можно непосредственно в браузере — и мы переходим туда.
Доставка ПО: посредством Облака. Если раньше, программа всё равно устанавливалась на компьютер пользователя и для него должна была быть отлажена, то теперь по сути нужно сделать программу лишь под один компьютер — сервер в Облаке. Для нас это удобно тем, что у нас есть полный контроль над этим компьютером и тем, как работают на нём наши программы. Конечно, остаются некоторые трудности с отрисовкой интерфейсов в браузере, но они гораздо менее серьезные чем те, что были раньше.
Всё это позволяет ускорить планирование, реализацию, тестирование. Больше нам не нужно месяцами или годами жить с чёрной дырой неизвестности: выстоит ли проект или нет, нужна ли в нём такая функциональность и т.д. Обновлять ПО можно практически в реальном времени.
Но в 2006-2008 идеологически ПО еще разрабатывается по-прежнему — как некое цельное ядро. Это, конечно, не exe'шник, но это всё равно цельный монолит, состоящий из набора очень плотно связанных объектов. Такое ПО слишком тяжеловесное, для того чтобы меняться так быстро, как этого хочет рынок.
Для решения проблемы неповоротливости монолита те же самые ребята, которые принесли нам ООП, говорят, что приложение можно и в целом разделить на отдельные программы, которые будут между собой коммуницировать. И тогда будет возможным ещё больше увеличить команду разработчиков — с сотен до тысяч — и создавать новую функциональность непрерывно. Тем самым проводить как можно больше экспериментов, проверять гипотезы, адаптировать бизнес под запросы рынка и действия конкурентов и двигать его вперед.
В 2009 году выходит первый доклад о том, как Dev и Ops объединяются, чтобы обеспечить 80 деплоев в день, и это становится одной из главных ценностей в разработке. Цикл разработки теперь выглядит совершенно по-другому:
- планирование — несколько недель;
- разработка — несколько недель;
- тестирование — несколько дней;
- доставка — несколько минут.
Ошибки можно исправлять практически на лету и разрабатывать гипотезу очень быстро. Тут же появляется всем известное теперь слово «MVP».
Если в 70-е у разработчика почти не было права на ошибку и ПО было фактически недвижимым — при запуске космонавтов на луну требования к функциональности не часто меняются — то теперь софт становится абсолютно динамическим. Все готовы к тому, что будут баги, поэтому и нужна поддержка и команда, которая будет обеспечивать работу системы в условиях динамичного развития.
В новой эпохе впервые за историю развития IT специальность, связанная с доставкой ПО, стала действительно «айтишной».
До этого профессия человека, который обеспечивал систематическую доставку программного обеспечения, вообще говоря, не была айтишной. В 70-80-е это были люди, которые засовывали перфокарты в компьютеры, в 80-90-е —люди, которые грамотно вели переговоры с фабриками и заводами по производству дисков и занимались логистикой. Это всё абсолютно не связано ни с разработкой, ни с системным администрированием.
Не погруженные глубоко в тему DevOps люди часто думают, что DevOps — это новое клёвое название для админов, которые больше общаются с разработчиками. Но бизнес (и википедия) считает, что DevOps — это методология внутри процесса разработки ПО. И не так важно, что конкретно она означает, — важно, что она дает. А дает DevOps как методология возможность максимально быстро адаптироваться к изменениям рынка и менять сам процесс разработки ПО.
Если компания не хочет отставать от конкурентов, то ей нужно переходить от длинных циклов разработки и релизов раз в месяц к DevOps. DevOps-трансформация при этом означает обеспечение Agile-процесса целиком — от разработки до выкладки. И таким образом процесс доставки ПО включается в процесс разработки и становится айтишной специальностью.
И да, поскольку процесс доставки обычно включает в себя работу, связанную с серверными и инфраструктурными штуками, то кажется, что это должен или может делать человек с админским бэкграундом. Но это приводит к проблеме во взаимопонимании инженеров и бизнеса. Особенно когда речь идет об админах, переживающих DevOps-трансформацию и выполняющих запросы бизнеса, который хочет быть гибче.
У большинства админов, которые занимаются обеспечением отказоустойчивости, идеология «работает — не трожь!» находится во главе угла. Они хоть и не запускают «Аполлон» на Луну, но мыслят теми же категориями надежности. А бизнес в новых условиях, пускай и ценой сбоев, хочет:
- минимальное время от идеи до продакшена;
- максимальное количество проверенных гипотез за короткое время;
- минимальное влияние ошибок на работу продакшена.
Пускай оно сразу упадет — это ничего, мы откатим, поправим и снова выложим. Лучше быстрее проверить, чем вкладываться во что-то, на что не будет спроса.
Подход к отказоустойчивости меняется: больше не нужно, чтобы текущая версия ПО была стабильной на протяжении долгого времени — нужно, чтобы ошибка в текущей версии ПО минимально влияла на работоспособность всей системы.
Не нужно обеспечивать стабильность маленького кусочка нового кода; нужно иметь возможность выкинуть его как можно быстрее и вернуть тот, который работал. Это опять про гибкость: ценность не в стабильности кода, который выложен в инфраструктуре, а в способности инфраструктуры быть максимально гибкой.
Как инженеру пойти навстречу бизнесу
Итак, что же мы можем сделать, чтобы найти больше пересечений с ценностями бизнеса?
Если мы говорим, что внедрение DevOps служит нуждам бизнеса, то должен быть способ понять, делает ли инженер то, что нужно бизнесу. Вот какие метрики можно ввести, если изучить отчёт DORA State of DevOps и исследование состояния DevOps в России:
- Частота деплоев (deployment frequency) — как часто вы деплоите код в продакшен или как часто ваши конечные пользователи получают новые релизы.
- Время внесения изменений (lead time for changes) — от коммита кода в репозиторий до его выкладки в продакшен.
- Время, за которое сервис восстанавливается после сбоя или аварии (time to restore).
- Частота аварий, вызванных выкладкой изменений (change failure rate) — какой процент деплоев приводит к ухудшению качества обслуживания пользователей и требует исправлений, например, откатов.
Эти метрики позволяют оценить, как компания использует возможности DevOps. В то же время, посмотрев на эти метрики, инженер может понять, какими своими действиями он может помочь бизнесу.
Частота деплоев
Понятно, что чем чаще компания деплоится, тем вернее она движется по пути DevOps-трансформации. Но деплоиться часто страшно. Однако DevOps-инженер может помочь справиться с этими страхами.
Страх 1: выложим что-то плохо протестированное, из-за чего продакшен упадет под нагрузкой.
Роль DevOps: обеспечить возможность легкого отката, помочь автоматизировать тестирование в инфраструктуре.
Страх 2: выложим новую функциональность с багами, а её внедрение изменит данные или структуру данных настолько, что откатиться будет невозможно.
Роль DevOps: работать в связке с разработчиками и помочь в архитектурных решениях, предложить эффективные методы миграции данных и т.д.
Страх 3: выкладывать долго и сложно (практика показывает, что 20 минут на сборку docker — обычная история).
Роль DevOps: обеспечить скорость деплоя и отката, ускорить процесс сборки.
Время внесения изменений
Это отчасти менеджерская метрика, потому что именно менеджер должен организовать процесс так, чтобы код, который написал разработчик, можно было максимально быстро закоммитить и задеплоить. Устранить препятствия на этом пути тоже может помочь DevOps-инженер.
Проблема 1: долго проходит pull request. Например, потому что есть ревью и ревью на ревью. В корне этой проблемы лежит всё та же боязнь выложить код.
Роль DevOps: работать с менеджером разработки в вопросе автоматизации принятия PR.
Проблема 2: долгий ручной процесс тестирования.
Роль DevOps: помочь автоматизировать тестирование.
Проблема 3: долгая сборка.
Роль DevOps: мониторить время сборки, уменьшать его.
Поэтому DevOps-инженеру нужно, во-первых, понять, как тестируется софт, как тестирование автоматизируется и как автоматизацию тестирования можно интегрировать в процесс сборки ПО. Во-вторых, разложить весь пайплайн выкладки ПО на составляющие и найти, где его можно ускорить. Замониторьте весь процесс от коммита до выкладки в продакшен, узнайте, сколько идет сборка, сколько pull request ждёт аппрува, и вместе с менеджером и разработчиками придумайте, на чём можно сэкономить.
Время восстановления работоспособности
Time to restore — время, за которое сервис восстанавливается после сбоя или аварии, — метрика, гораздо более близкая к SRE.
Проблема 1: сложно локализовать техническую проблему.
Роль DevOps: организовать observability, вместе с разработкой обеспечить инфраструктуру для мониторинга и настроить систему мониторинга так, чтобы эффективно следить за работой сервиса.
Проблема 2: инфраструктура не готова к легкому процессу «отката».
Роль DevOps: обеспечить техническую возможность.
Проблема 3: после миграции невозможно откатиться.
Роль DevOps: научить разработчиков практикам миграции данных, позволяющим легкие откаты, и практикам отказоустойчивости.
Частота аварий
Change failure rate — как часто выложенный код падает — это снова про менеджмент и идеологию, но здесь есть интересный момент: код часто падает, если его редко выкладывать.
К сожалению, я видел случаи, когда компания берет курс на DevOps-трансформацию, внедряет GitOps и Kubernetes, но частота релизов от этого не меняется. Подход остаётся прежним, и разработка новой версии как занимала полгода, так и занимает полгода. А если вы пишете код, который на протяжении месяцев не выкладываете в продакшен, то он упадет с гораздо большей вероятностью, чем код, который выкладывается каждую неделю. Этого разрушает весь процесс целиком: если компания взяла курс на DevOps, а при этом цикл разработки занимает шесть месяцев, то это какая-то беда.
В таком случае DevOps должен забить тревогу и попытаться ещё раз объяснить суть DevOps-подхода и то, как изменился подход к разработке за последние годы.
Дивный новый мир
Нам как инженерам нужно понимать, что же важно для бизнеса, и на это и направлять свои усилия.
- Стабильность текущей версии кода не так важна, как стабильность инфраструктуры целиком и возможность откатиться к предыдущей версии, изолировать проблему и быстро её исправить.
- Стабильность окружения разработки, его производительность критически важна, особенно если в команде сотни разработчиков. Когда разработчики из-за проблем со средой разработки вынуждены ждать, это равносильно простою фабрики.
- Мониторинг процесса доставки ПО стал частью мониторинга всей инфраструктуры. Если что-то выкладывается 20 минут, то надо попытаться это ускорить.
- Скорость доставки ПО становится одной из ключевых задач, нужно обеспечить такую молотилку и чтобы она при этом работала как часы.
- Создание удобных окружений для разработки — ещё одна ключевая задача. Если разработчику удобно, он пишет код быстрее, чаще выкладывает и всё работает хорошо.
Подписывайтесь на наш блог, здесь мы регулярно публикуем интересное из мира DevOps и рассказываем о случаях из нашей практики, которые помогут, например, подготовить сервисы к чёрной пятнице. Или подключайтесь к моему телеграм-каналу — там я собираю мысли на профессиональные (и не только) темы и делюсь любопытными ссылками.
Автор: Евгений Потапов
