DevOps для бабушки
Тут где-то мелькало, что сложно бабушке про DevOps рассказать. Я попробую.
▍Ба, надо поговорить
Ты вот порой ругаешься, когда у тебя в телефоне программы тормозят. Ну, ты у меня уже знаешь, что называются эти программы «приложения» и делают их программисты. Они работают в компаниях-разработчиках приложений. Но, чтобы сделать и выпустить такое приложение-программу, а также технически поддерживать её — исправлять ошибки (чтобы не она тормозила, например), добавлять новые полезные и удобные для тебя функции — нужны не только программисты, а целый штат разных специалистов.
Это те, кто придумывает, что должны делать эти программы, анализирует, кому они могут понадобиться, каким целям бизнеса они будут служить (ну, конечно, люди же деньги зарабатывают через оказание тебе услуги). Есть те, кто планирует, где и как потом рекламировать приложение, чтобы его устанавливало множество людей, какие функции сделать платными (ну, конечно…). Дизайнеры придумывают, какого цвета кнопки будут в приложении, как их расположить, чтобы удобней было пользоваться и прочее юзабилити (от английского usability — «удобство и простота использования»). Программисты, конечно, самые крутые на мой взгляд — они пишут программный код, чтобы всё это работало, причём работало правильно. Если будет работать неправильно — они будут что-то переписывать, да так, чтобы от этого переписывания другие функции не перестали работать. Тут прям логика нужна недюжая.
В хорошем дизайне, кстати, тоже логики немало. Да ещё и художественный вкус нужен, чтобы у пользователей кровь из глаз не текла, когда они открывают приложение. Да не бойся, это просто так говорят, когда неприятно смотреть на дизайн. Да, да, вот те мелкие оранжевые буквы на чёрном фоне и куча разных шрифтов, именно! Ещё есть тестировщики, которые тестируют части написанного программистами кода и, если находят ошибки, отправляют на доработку (да, можно не всё сразу тестировать, а кусками — хм, а ты начинаешь понимать). И есть те, кто потом, когда приложение после разных тестов и исправлений ошибок выходит на рынок, следит за обратной связью от пользователей. Ага, отзывы. Великая вещь! Этот мониторинг позволяет понять, что надо исправить, какие функции добавить или отключить.
В общем, народу много и набор специалистов зависит от масштаба и типа проекта: есть ведь приложение-игра, например, а есть мобильный банк. Разные же вещи. Ах да, есть ещё тот, кто всей этой командой управляет. Так вот, насчёт команды. Взаимодействие в ней может быть разным. И от того, какое оно, зависит и скорость выпуска приложения, и скорость его обновления, и стоимость его разработки. Как «зачем скорость»? Потому что пока одни долго думают что, куда и как — другие уже быстренько всё напишут, выпустят и соберут сливки (ну, конечно…). Вот раньше так и было — медленно. А теперь DevOps. Сейчас поймёшь.
▍Как раньше выпускали приложения (каскадная модель разработки)
Лет 10–15 назад в разработке в основном применяли так называемую каскадную модель. Это когда все фазы производства приложения последовательно перетекали одна в другую, как будто вода течёт по ступеням сверху вниз. Вначале собирались менеджеры, маркетологи и другие специалисты, которые придумывали идею приложения или программы для компьютера. В первой фазе определяли требования к будущему «продукту». Потом техническое задание с требованиями передавали программистам, которые делали проект приложения. Когда проект согласовали, он переходил в фазу разработки (написания программного кода в виде текста) и сборки (когда этот текст переводят в компьютерный код). Эти фазы сейчас условно объединяют под термином DEVelopment — разработка.
После этого наступает фаза тестирования. После своей серии работ на тестовых компьютерах тестировщики передают программу в отдел эксплуатации, где код устанавливают уже на рабочие компьютеры — запускают в боевом режиме, выводят на рынок. Люди пользуются программой, оставляют отзывы — автоматически ведётся статистика всяких всплывающих ошибок. Администраторы отдела эксплуатации мониторят эту обратную связь: собирают претензии пользователей и результаты статистики. А затем передают программистам, чтобы те исправляли ошибки и добавляли новые функции, если надо. Эту фазы относятся к периоду OPeration.
▍У каскадного подхода к разработке было много минусов
Во-первых, разработка велась долго. Очередная фаза наступала только после полного и успешного завершения предыдущей. Фазы не перекрещиваются, не параллелятся. При обнаружении ошибки или необходимости внесения новой функции, когда уже всё написано и протестировано, приходилось заново проходить все этапы постепенно. Время-то идёт, а конкуренты не спят.
Во-вторых, не было согласованности между отделами. Это вообще была головная боль. Например, тестировщики тестируют код неделю, а потом оказывается, что уже давно написана новая версия кода, а они тестируют старую. А программисты вообще не знают, что происходит с кодом после того, как он вышел из их отдела. Ну ладно, как-то там разобрались, потратили ещё кучу времени на новые тесты, отправили в отдел эксплуатации –, а ничего не работает. Почему? Потому что у них компьютеры иной конфигурации, чем те, на которых писали и собирали код. Это у них классика была. Даже враждовали.
А всё это потраченное время оплачивал заказчик. Представь, тебе бы пришлось, как заказчику, платить в 5 раз больше за такую долгую неразбериху, а в итоге бы оказалось, что пока год делали приложение, какие-то функции уже не нужны пользователям или они должны быть другими. Мочало, начинай сначала. И, кстати, эту новость отдел разработки получает не сразу, как о ней стало известно, а тогда, когда отдел эксплуатации соберёт кучу пользовательских отзывов, проанализирует их, что-то там отсеет и пачкой передаст их программистам. И пока они всё исправляют, остальные сидят без работы. Потом тестировщики тестируют — остальные сидят без работы. Жуть и сплошные растраты. Ну и обстановочка в коллективе не фонтан, что тоже сказывается на процессах и результатах.
▍Как выпускают приложения сейчас (горизонтальный зацикленный поток)
Помнишь слова DEVelopment и OPeration? Да, разработка и эксплуатация. Так вот, придумали такую методологию организации процесса разработки, когда её фазы перетекают друг в друга как бы в горизонтальном потоке, причём непрерывном — представь течение в русле восьмёрки. Точно! Бесконечность. Да ты у меня продвинутая. И назвали эту методологию DevOps, по первым буквам этих английских слов, акроним, ага.
При таком подходе не каждый отдел отвечает за свою часть, а все вместе за всё приложение. Есть тесная связь между специалистами. На этапе определения требований участвуют все и уже там программисты могут сказать своё слово, про то, как лучше и быстрее проектировать; дизайнеры своё слово; маркетологи своё; уже можно определить подходящие инструменты для автоматизации некоторых процессов. Автоматизация, кстати, важнецкий элемент DevOps, но о ней позже. Фазы проектирования, написания кода, тестирования, запуска и поддержки приложения переходят друг в друга моментально и непрерывно по мере поступления задач. Все всегда заняты: одновременно можно писать одну часть кода, тестировать другую, вносить правки в третью, развёртывать четвёртую. Этот процесс называется CI/CD — сочетание непрерывной интеграции, то есть самой разработки (англ. continuous integration) и непрерывной доставки, то есть развёртывания (англ. continuous delivery или continuous deployment). Это жизненный цикл разработки программного обеспечения в DevOps.
▍У DevOps-модели разработки есть много плюсов, перекрывающих минусы каскадной модели
У команд разработки, использующих DevOps-подход, приложения выходят гораздо быстрее, чем при каскадном подходе. Есть одна специальная программа для CI/CD, ей пользуются десятки миллионов людей. Её производитель, известная компания GitLab, периодически проводит разные исследования в своей сфере. Так вот Пятый ежегодный глобальный опрос GitLab по DevOps 2021 года показал: 57% респондентов сообщили, что код выпускается в два раза быстрее, что значительно больше прошлогодних 35%, а 19% заявили, что код выпускается в 10 раз быстрее!
При DevOps нет постепенной работы, она параллельная во всех отделах. Да и границы между отделами (специалистами) стираются — часто это общая группа, где все работают над всеми фазами приложения (жизненным циклом), развивая не только свои узкоспециализированные навыки. На обратную связь от пользователей реагируют быстро, тут же исправляют ошибки. При тестировании стало гораздо меньше ошибок, свойственных этому процессу и замедляющих его. И самое главное — расходы на создание и поддержку приложения снижаются тем больше, чем быстрее оно выпускается.
Многие процессы раньше выполнялись вручную, медленно, узкими специалистами. А команды DevOps используют такие технологии и программные инструменты для автоматизации этих процессов, которые позволяют не только сильно ускорить процессы, но и выполнять инженерам некоторые задачи без привлечения других отделов, минуя всякие согласования и прочую бюрократию (например, подготовку IT-инфраструктуры или развертывание кода). В том же отчёте GitLab говорится: «Большинство (55%) операционных групп сообщают, что их жизненные циклы были полностью или в основном автоматизированы. Для сравнения, в 2020 году только 8% команд заявили о полной автоматизации. Интегрируя автоматизацию в свои циклы разработки, члены команд DevOps получают драгоценное время для решения других задач. Операционные группы, например, изменили приоритеты, чтобы соответствовать новому ландшафту индустрии программного обеспечения, сформированному событиями 2020 года».
▍Как автоматизируют процессы в DevOps
Любую задачу в разработке можно автоматизировать, представляешь? Автоматизация всё ускоряет, упрощает, минимизирует человеческий фактор (ошибки). Программ (инструментов) для автоматизации процессов разработки много, в них обилие функций. Например, это инструменты для:
- Разработки — с их помощью отслеживают процесс создания кода и все изменения, внесённые в его разные версии. Если добавили новые функции и что-то сломалось, то они позволяют откатить эту версию до конфигурации, работавшей до изменений. Их ещё называют системы управления версиями (например, Git).
- Сборки — системы CI/CD (наш GitLab, а ещё известны Bamboo, Jenkins). Там выполняются скрипты (короткие описания действий, которые должна совершать система, написанные на языках программирования), происходит автоматическое тестирование и доставка протестированных частей соответствующим департаментам для дальнейшей работы.
- Развёртывания — автоматизируют развёртывание инфраструктуры и управление приложениями в «облаке» (Об облаках в другой раз, если этот ликбез тебе понравится. Коротко: это когда берут мощности удалённого компьютера в аренду и используют их через интернет. Очень выгодное дело). Это так называемые системы управления инфраструктурой как кодом (IaC) Например, Terraform, Ansible.
- Облачных технологий— помогают автоматически управлять нагрузками на систему, то есть снижать и увеличивать объёмы арендуемых мощностей в зависимости от нагрузки в определённые дни. Ну, чтобы не переплачивать за простой мощностей или чтобы не было сбоя в приложении из-за того, что им пользуется много людей одновременно, как в дни распродаж в интернет-магазинах, например (Да-да, поэтому и выгодно. Ба, ну ты голова!). Масштабирование называется. Ну и в целом автоматизируют рутину. Это инфраструктура, которую за тебя создадут и отладят в качестве сервиса (IaaS) или платформа под отдельные задачи как сервис (PaaS).
- Сред выполнения — это оркестраторы контейнеров (Об этом тоже в другой раз. Коротко: приложение может быть не целикашным, а разбитым на компоненты. Эти разные компоненты приложения и программные правила о том, как они должны работать, располагаются в изолированных друг от друга частях компьютера — контейнерах, но все вместе они связаны с главным общим двигателем. Это удобно тем, что нет опасности сломать всё приложение, если вносят изменения в какую-то его микро-часть). Контейнеров могут быть тысячи и ими надо управлять — это и делают оркестраторы. Ещё они облегчают процессы развёртывания, тестирования, запуска и другие.
В общем, DevOps — это методология оптимизированной организации процессов при разработке приложений. Помогает всё ускорить, автоматизировать и удешевить = больше заработать за относительно короткий промежуток времени. Времена-то у нас быстрые, как ты заметила.
▍А давай-ка замутим пирожков по DevOps-у?
С мясом и рисом. И сладеньких ещё, с яблоками. Говоришь, просто с рисом будет невкусно и хорошо бы добавить варёное яйцо? Согласна, так вкуснее. А пирожки будем жарить или печь? Да, я тоже больше люблю печёные. К тому же, это быстрее. Распределим их по контейнерам, то есть противням, которые можно будет менять местами по мере готовности: сверху и снизу они быстрее пекутся, а в середине — медленнее. Отлично, проект готов.
Где будем готовить и какие инструменты нам нужны? Будем делать много? Значит выдвигаем большой стол для раскатки теста. Месить будем в миске или прямо на столе? Ок, стол. Да, и уже пора бы начинки приготовить. Вот кастрюли, мясорубка, прочее… Руками, правда, тесто месить долго будем. Говоришь, есть планетарный миксер? Да ты схватываешь на лету! Автоматизируем.
Давай ты будешь тестом заниматься, а я начинкой. Ок, попробуй, как тебе мясная на соль? Отлично, но перца не хватает? Добавляем. Греем духовку, лепим. Давай я буду лепить, а ты забирай и выкладывай на подготовленные противни — будет конвейер. И что там дальше надо делать? Ну, ты сама знаешь — типа, смазать желтками и прочее. Сначала испечём тестовые пару штук? Ба, ты умница.
Так, я бы добавила корицу в яблочные. И жареный лучок в рисовые? Ок, добавляем. Ну, что, делаем всё на «боевых»? Следим за температурой, меняем противни местами и пирожки на них, чтобы с краёв не подгорели. Первую партию отнесём попробовать остальному семейству — интересно, что скажут? Ага, хотят, чтобы пирожки с мясом были с корочкой и чуть более солёные. Ок. Досаливай оставшееся под них тесто, я леплю, а ты клади на верхний противень. А я пока в это время помою посуду и стол.
Ну что, отлично потрудились и быстро сделали вкусные пирожки. Ещё и на масле сэкономили. А насчёт того, что у тебя приложение тормозит — ты вот не поленись и отзыв напиши. Вдруг ребята тоже DevOps-еры, как мы с тобой? Тогда они быстро промониторят твой отзыв и сообщение о сбое уйдёт программистам. Они там добавят соли с перцем.
