DevOps — очень модное слово. Ещё не такое модное, как «нейронные сети», «блокчейн» или «стартап». Но оно давно на слуху у всех, кто хоть как-то связан с новейшими IT-решениями. Сайты с вакансиями ломятся от объявлений «Ищем DevOps-программиста». А падкие на наживу блогеры клепают статьи в духе «Простое руководство по DevOps».

При этом, несмотря на всю трендовость, большинство людей даже не знают, как расшифровывается акроним DevOps. Похоже, что это как секс в старшей школе: про него все говорят, но на самом деле реальный опыт был только у одного незаметного хорошиста на задней парте. Да и тот случайный.

Уважаемые рекрутеры, программисты, блогеры и любители новомодных явлений — запомните! DevOps — не профессия, не технология и не половая ориентация, это культура.

Как появилась концепция DevOps!

Ноги этой культуры растут из Японии. Но не из той Японии, в которой школьницы ходят в плиссированных клетчатых юбках и говорят похотливыми голосами. А из той, в которой скромные, тихие и чертовски умные японские работяги и инженеры строят лучшие в мире автомобили, а после работы налегают на удон с тонкацу и рисовое пиво. Если говорить конкретно, корни концепции DevOps лежат на заводах Toyota.

Японцы любят долго и медитативно изучать процессы, доводя форму вещей и явлений до совершенства. Японская поэзия, японское оружие, японская еда — все это лаконично, функционально, изящно и прекрасно. Этот же подход азиатские мастера здравого смысла применили и на заводе Toyota, в результате чего производство автомобилей стало четким, лаконичным и безошибочным, как удар катаны самурая.

Принципы менеджмента, выработанные Toyota, сделали машины этой компании самыми надежными в мире, а бизнес — самым стабильным и прибыльным среди всех производителей автомобилей. И все это спокойно, размеренно и с достоинством.

Как расшифровывается DevOps

Перед внедрением принципов менеджмента Toyota в разработку прошло некоторое время, к этому привели некоторые предпосылки, которые мы рассмотрим ниже.

Общепринятое сейчас определение DevOps — методология разработки программного обеспечения, сфокусированная на активном взаимодействии команды: программистов, тестировщиков и администраторов, которые обслуживают один сервис или продукт. DevOps внедряют в стартапах и мелком бизнесе, в среднем бизнесе и крупных проектах.

Что было до эпохи DevOps

В свою очередь, IT-индустрия долгое время была своеобразной лотереей. Сроки по проектам превышались, бюджеты перерасходовались, команды из лучших в стране специалистов могли легко выпустить на рынок абсолютно негодный продукт. Проблемы с выпуском ПО были у всех компаний, независимо от размера, выручки и адекватности персонала.

Даже всемогущее ФБР однажды село в лужу, попытавшись запустить новую систему документооборота — Sentinel. А в результате, подрядчики сожрали сотни миллионов долларов, написали миллионы строк кода, превысили сроки в несколько раз — и выпустили программу, которая была настолько плоха, что ее пришлось просто выбросить.

Как внедрение DevOps стало модным

В середине нулевых, долгие годы мытарств спустя, несколько ключевых разработчиков из крупных американских компаний одновременно пришли к одной и той же светлой идее — принципы японского менеджмента и работы DevOps можно применить к разработке ПО. И, представьте себе, чудо произошло! Выпуск новых версий софта перестал походить на лотерею, сроки и бюджеты внезапно стали соблюдаться, а качество продукта сильно выросло.

Основные задачи DevOps

В деталях процесс применения японских законов в IT описан в руководстве DevOps Handbook. Книга увесистая, но полезная. Для нас же из всей практики в первую очередь важно несколько ключевых принципов:

  1. Заставить разработчиков софта (Dev) говорить с теми, кто этот софт эксплуатирует (Ops) — админами, тестерами и, по возможности, пользователями. Быстрый и ежедневный обмен информацией между всеми участниками процесса дает лучшее понимание актуальной ситуации, это одна из важнейших задач DevOps. Если программисты написали глючный код — им об этом оперативно скажут еще на этапе настройки новой версии на сервере, а не в тот момент, когда продукт доедет до конечного пользователя.
  2. Скорость. До 2010-го года ПО было принято релизить редко. Обновления собирались неделями, а последствия выкатки новых релизов иногда обрушивали какие-нибудь критические системы. Принцип DevOps требует релизиться минимум 3 раза в неделю. И это не предел — многие крупные компании обновляют свои сервисы по 20-50 раз в день, ничего не ломая и не роняя. А чем быстрее команда разработчиков выкатывает обновления — тем быстрее к ним приходит обратная связь от админов и юзеров.
  3. Автоматизация. DevOps (и японский менеджмент) требуют избегать лишних потерь. А одна из самых страшных потерь в бизнесе — потеря времени. Именно поэтому команды айтишников автоматизируют все, что можно. Сборка новых версий, тестирование софта на всех уровнях, сбор отчетов, управление серверами — все это происходит без участия человека и без траты времени инженеров.
  4. Инфраструктура как код. Все правила конфигурации серверов, сетей, операционных систем и сред для запуска ПО тщательно документируются вместе с кодом. Благодаря этому подходу серверы можно больше не чинить. Их можно сразу отправлять на помойку и при этом экономить кучу времени и денег. Если что-то перестает работать — сервер просто выбрасывается, а вместо него включается новый, который конфигурируется готовым скриптом. До 2010-го года к серверам было принято относиться, как к единственному трактору на ферме — за ними следили, чинили, постоянно настраивали и оптимизировали. В наше же время к серверам относятся как к лошадям на Диком Западе: в случае проблем — пристрелить и сесть на другую.

Внедрение DevOps и облака

В 2018 году концепцию DevOps невозможно представить без облачных технологий. И на это есть несколько причин.

Инфраструктура, описанная в виде кода, буквально создана для облаков. Нужен тестовый сервер — просто запусти файл сценария, и все сценарии настроек автоматически применятся к новой железке. Полученный сервер можно использовать для тестов, разработки или как стейджинг сервер для запуска нового кода в боевых условиях. А админам достаточно всего один раз описать сценарии для запуска нового железа, чтобы впоследствии эти файлы можно было повторно использовать годами.

Дешевизна, скорость развертывания и гибкость настройки облачных серверов подарили нам возможность больше не чинить их. Введение в строй виртуальных железок занимает секунды, а не часы, как было с железными серверами. Если что-то пошло не так в ходе развертывания нового сервера — его можно выкинуть, вернуться к предыдущей версии сценария конфигурации, в которой всё работало, и поднять новый сервер, а не тратить время на поиск и исправление проблем в настройках.

Облачная инфраструктура поставляется с уже предустановленными решениями — готовыми СУБД, объектными хранилищами и сервисами контейнеризации. Это все сокращает временные и финансовые издержки на настройку инфраструктуры. В итоге операционная команда может сфокусироваться на скорости и производительности кода, а не на развертывании баз данных, запуске веб-серверов и бесконечном редактировании файлов настроек.

С облаками проще коммуникации внутри команды, а значит, концепция DevOps точно будет работать. Развертывание сервиса в облаке — более простая операция, чем конфигурирование сервисов вручную на физических серверах. Тогда разработчикам гораздо понятнее, что делают админы. Это понимание дает возможность обсуждать проблемы эксплуатации и находить решения вместе. Все члены команды говорят на одном языке, видят все файлы проекта в общем доступе и имеют общее для всех понимание ситуации.

Работа с DevOps — сила, традиции — могила

Лучшие из лучших IT-компаний мира применяют концепцию DevOps ежедневно. И мы все пользуемся плодами этой культуры. Раньше выпуск новой прошивки для принтера занимал 2 года, а сейчас за пару месяцев ребята на заводе Tesla полностью обновляют автопилот для машины.

Без DevOps-практик быстроразвивающиеся интернет-сервисы (речь про системы управления заводами и военные системы пойдет в другой статье) обречены отставать от конкурентов, постепенно погружаясь в болото посредственности, в котором новые версии продукта выпускаются раз в год, а клиенты месяцами ждут исправления багов и новых фич.

Для быстрорастущих компаний с их взрывным ростом и кратным увеличением нагрузок и скоростей DevOps культура и более традиционные подходы — это не выбор между модным словом и классикой, это выбор между экстремальной эффективностью или смертью вашего бизнеса. И в 2018 году этот выбор пока еще не поздно сделать.