Разбираю, какие операции у вас выполняются руками по чьей-то памяти, и перевожу их в идемпотентные плейбуки: разворот окружения, обновление базы, проверка безопасности, бэкап с восстановлением, выкатка с откатом. Отсюда и название: не только dev и ops, а все операции — кодом.
Бесплатно — 20 минут разговора, чтобы понять, что у вас делается руками и что из этого стоит автоматизировать.
Восемь вопросов про операции, которые выполняются регулярно. Отвечать никому не нужно — это для себя
Если поднять копию прода можно только руками и по памяти одного человека, то тестового контура у вас фактически нет, а любая проверка идёт на бою.
Когда на стейдже и на проде разные шаги, разница между ними накапливается молча и всплывает в худший момент.
Скрипт, который ломается при повторном запуске, нельзя применить после сбоя. А сбой случается именно в середине.
Если hardening делался один раз руками при установке, то текущее состояние серверов не знает никто, включая того, кто их настраивал.
Каждый ручной шаг в этой цепочке — место, где однажды ошибутся. Их количество стоит хотя бы посчитать.
«Откатимся из бэкапа» — это не откат, а восстановление. Разница в часах простоя и в том, теряются ли данные за последние сутки.
Если ответ начинается со слов «ну, надо будет вспомнить» — время восстановления измеряется памятью, а не документом.
Автоматизация нужна не ради красоты. Она переводит знание из головы в репозиторий, где оно доступно любому.
Каждое «делается руками по памяти» — это не лень, а нормальное состояние системы, которая росла быстрее, чем её успевали описывать. Вопрос только в том, сколько таких мест и какое из них выстрелит первым.
Не «берём эксплуатацию на себя», а делаем так, чтобы её мог вести кто угодно
Поднятие сервера, базы, окружения с нуля — не инструкцией в вики, а плейбуком, который выполняется одной командой и даёт одинаковый результат на любой машине.
Накат версий и схемы — процедурой с проверкой состояния до и после, а не последовательностью команд, которую кто-то помнит.
Hardening и аудит — не разовое действие при установке, а прогон, который можно повторить в любой момент и сравнить с прошлым результатом.
Восстановление — такая же автоматизированная процедура, как и бэкап. Иначе первый её запуск случается в день аварии.
Путь от коммита до прода, описанный целиком, вместе с обратной дорогой. Откат — отдельная процедура, а не «поднимем из бэкапа».
Метрики и алерты, заведённые кодом вместе с сервисом, а не накликанные в интерфейсе после того, как что-то упало.
Общее правило у всех шести: процедуру можно запустить повторно, и она не сломает то, что уже сделано. Это и есть идемпотентность — разница между плейбуком и скриптом, который «работает, если запускать в правильном порядке».
Артефакты, а не обещания: всё перечисленное лежит в вашем репозитории
Последний пункт важнее остальных: плейбук, который никто не запускал, ничем не отличается от инструкции в вики. Приёмка этапа — это запуск процедуры на вашей инфраструктуре, а не демонстрация кода.
Подписка на эксплуатацию с фиксированным SLA. Прозрачно, помесячно, без «человеко-часов»
Посмотреть на вашу эксплуатацию со стороны, ответить на конкретный вопрос. Без обязательств продолжать
Составляю реестр операций: что делается руками, как часто, сколько занимает и чем рискует. Отдаю план автоматизации по приоритету
Пишу плейбуки по утверждённому плану и прогоняю каждый на вашей инфраструктуре. Этапами, приёмка — запуск процедуры, а не показ кода
Чтобы не тратить ваше и своё время на созвон, который кончится отказом
Одним инженером оно не закрывается. Если вам нужна гарантированная реакция в три часа ночи, нужна смена из нескольких человек, и честнее сказать это сразу.
Ежемесячный платёж за готовность — не моя модель. Я беру конкретную работу, довожу её до результата и передаю. Возвращаться можно, зависеть от меня — не нужно.
Беру задачу и отвечаю за результат. Позиция внутри чужой иерархии с согласованием каждого шага подходит плохо обеим сторонам.
Если задача звучит как «делай это каждую неделю руками», мой ответ — «давайте я это автоматизирую один раз». Если автоматизировать нельзя, задача не моя.
Нельзя описать кодом процесс, который никто не может объяснить словами. Сначала разбор, потом плейбук — в обратном порядке получается закреплённый в коде беспорядок.
От «эксплуатация как получится» к предсказуемому сервису под SLA
Составляю реестр операций и смотрю, как каждая выполняется сейчас. Без этого автоматизировать нечего — можно только закрепить в коде существующий беспорядок
Фиксирую, что переводим в код первым: по частоте, по цене ошибки и по тому, сколько людей завязано. Прозрачная смета и сроки
Пишу плейбуки и прогоняю каждый на вашей инфраструктуре. Этап принят тогда, когда процедура отработала при вас, а не когда написан код
Отдаю репозиторий, runbook и реестр. Дальше процедуры запускает ваша команда — в этом и смысл работы
Открытый стек и индустриальные стандарты — без вендор-лока
Штатный инженер решает задачи по мере поступления, и знание о том, как всё устроено, остаётся у него в голове. Я делаю обратное: превращаю операции в код, который лежит у вас в репозитории и работает независимо от того, кто его запускает. После моей работы вам нужно меньше людей на эксплуатацию, а не больше. Абонемента, на котором вы бы от меня зависели, нет.
Ни то, ни другое. Я не занимаю его место и не встаю рядом на дежурство. Я забираю у него рутину: те процедуры, которые он выполняет руками каждую неделю, после автоматизации запускаются командой и перестают есть его время. Обычно это и есть причина, по которой он не успевает делать более важные вещи.
Работаю по минимально необходимым правам, через именованный доступ, без общих паролей. Для разбора обычно хватает доступа только на чтение. Всё, что я делаю на этапе реализации, лежит в вашем репозитории в виде кода — то есть проверяется до запуска и откатывается после. При необходимости подписываем NDA.
SLA у меня нет, и это осознанно: гарантировать время реакции круглосуточно один инженер не может, а обещать то, что не выдержишь, хуже, чем сразу сказать «нет». Моя работа — сделать так, чтобы реакция требовалась реже: процедура восстановления запускается одной командой, и для этого не нужен именно я.
Да, и обычно так и стоит. Начните с консультации на час: разберём одну конкретную операцию, которая больше всего раздражает. Если после этого разговора станет понятно, что таких мест много, есть смысл делать полный разбор.
Тем лучше — значит, часть пути пройдена и ломать это незачем. В разборе я смотрю не на то, есть ли инструменты, а на то, какие операции всё ещё выполняются мимо них. Обычно это разворот окружений, работа с базой и всё, что связано с восстановлением.
Оставьте контакт — разберём вашу инфраструктуру, честно скажем, что берём на себя, и предложим подходящий тариф
Отвечу в ближайшее время. Без спама и навязчивых звонков.