Текстовый курс по DevOps
Как наладить непрерывное обучение в DevOps?
Вы уже знаете по своим проектам, что даже с контрольными списками, коллегиальной проверкой, контролем, аудитами и процедурами соблюдения требований проблемы всё равно возникают. Пора создать в команде и организации DevOps культуру самостоятельной диагностики, обучения и совершенствования. Такая культура признаёт, что проблемы неизбежны, и команды готовы к ним. Решение проблем должно стать частью повседневной работы и помогать организации непрерывно учиться и развиваться. Чтобы умножить пользу от найденных решений, сделайте их открытыми и легко доступными во всей организации DevOps.
Netflix, одна из ведущих организаций DevOps, создала собственное ПО Chaos Monkey, чтобы имитировать серьёзные сбои в облачных ЦОД. Chaos Monkey случайным образом выводит серверы рабочих систем из строя, чтобы команда Netflix могла убедиться в устойчивости, стабильности и бесперебойном качестве обслуживания клиентов. Из каждого сбоя команда извлекает уроки и применяет их, чтобы сделать системы ещё стабильнее и устойчивее.
Почему важно создать культуру обучения
Если после инцидентов в организации принято искать виноватых, инженеры начинают бояться ошибок. Организация становится медленной и бюрократичной, а её работа зависит от внутренней политики. Вместо того чтобы осознанно учиться на ошибках, повышать устойчивость к сбоям и внимательнее их предотвращать, сотрудники стараются обезопасить себя. Работа, проблемы и даже решения никогда не становятся полностью прозрачными.
Because problems are inevitable in complex systems, instead of finger-pointing, blaming and shaming the ones who cause problems, your organization should value actions to make problems visible in your daily work. It should encourage organizational learnings from errors and inefficiencies, so everyone in your DevOps organization can also learn and profit from these problems, solutions and knowledge.When engineers in your DevOps organization feel safe about giving details about mistakes, they voluntarily go extra mile and spend a lot of energy to make sure that a similar problem will not happen again in their own work center and in other work centers in your organizational value stream. If engineers are punished or even if they feel that they are punished when they do mistakes, then they will be afraid of making mistakes, so
- Выполняют меньше работы, чтобы меньше ошибаться.
- Скрывают работу, проблемы и решения.
- Не видят причин превращать решения проблем в знания для организации.
- Та же или очень похожая проблема неизбежно повторится, поскольку никто не тратит время и силы на изучение проблем и решений, обмен опытом и обучение коллег.
Проводите разбор сразу после инцидента, пока не забылись его причины
Цели разбора инцидента просты:
- Определить, что вы сделали правильно, чтобы повторить эти действия в похожих ситуациях.
- Отметить, что стоило сделать иначе, чтобы в будущем улучшить свои методы.
- Отметить, что вы сделали неправильно, и предложить альтернативные подходы или меры предосторожности для следующей подобной ситуации.
- Выяснить, почему имело смысл предпринять или не предпринимать действие, которое привело к инциденту.
Разбираться в своих ошибках бывает страшно, а в некоторых организациях и опасно. Если признание ошибки грозит критикой или наказанием, вряд ли вы в ней признаетесь. В конечном счёте такой подход вреден: если вы не поймёте прошлую ошибку, скорее всего, повторите её. Организации, которые всерьёз стремятся к улучшениям, это понимают и прилагают усилия, чтобы создать процесс и культуру, в которых ошибки можно спокойно изучать.
Начиная разбор инцидента, примите несколько основных положений:
- Каждый старается сделать свою работу как можно лучше в пределах своего понимания.
- Решения приходится принимать в напряжённых ситуациях, не имея полной информации.
- Вам часто приходится выполнять задачи, к которым вас не готовили, с теми инструментами и ресурсами, что оказались под рукой.
- В таких ситуациях ошибки неизбежны.
- Цель разбора — понять, что произошло и какие уроки из этого можно извлечь. Искать виноватых или осуждать их действия не нужно.
- По итогам разбора оценивают процессы и способы их улучшения, а не отдельных людей или группы.
Крайне важно, чтобы все участники приняли этот принцип: «Мы здесь, чтобы учиться, и никого не обвиняем». Многие организации прилагают большие усилия, чтобы создать такую безопасную среду. Например, у FAA действует система сообщений о безопасности полётов (Aviation Safety Reporting System), в рамках которой пилоты, допустившие «ошибки», могут избежать дисциплинарных мер со стороны регулятора, если сообщат об инцидентах.
По итогам разбора инцидента всегда определяйте конкретные меры, которые помогут избежать повторения. Например, новые метрики телеметрии и автоматизированные тесты, выделение типов изменений, требующих дополнительной проверки кода, рефакторинг или разделение тесно связанных компонентов, часто вызывающих проблемы.
Публикуйте протоколы разбора и извлечённые уроки так, чтобы они были доступны всей организации. Так опыт одного участка потока создания ценности станет знанием всей компании. Это также покажет, что в вашей DevOps-организации ценят прозрачность, открытость и обучение.
Проводите учения по сбоям, чтобы улучшать системы
Учения по сбоям — не очередное скучное командное мероприятие, где экстраверты наслаждаются происходящим, а интроверты сидят в телефонах, чтобы время шло быстрее.
На учениях в тестовых системах имитируют серьёзные отказы. Команды DevOps устраняют последствия и учатся на этих сбоях.
Например, останавливают критически важный сервер, чтобы проверить, сработает ли переключение при отказе без перерыва обслуживания. Затем команда DevOps проверяет, работает ли восстановление из резервных копий или из инфраструктуры как кода (IaC) и как именно. Выявление проблем при таких сценариях помогает создавать устойчивые, отказоустойчивые системы и приобретать новые знания.
Устраняя проблемы и отрабатывая сценарии отказа без лишнего стресса, команда DevOps налаживает отношения с другими подразделениями. Вы проверяете взаимодействие и устранение неполадок и получаете возможность улучшить эти процессы во всей организации.
Вы также заметите слабые сигналы более серьёзных проблем, которые могут проявиться в будущем. Частые инциденты низкого приоритета во время учений или небольшой побочный эффект, который едва не вывел из строя другой критический компонент, — важные сигналы. Разберите их и используйте для улучшения систем.
ВЫВОДЫ
Поощряйте команду DevOps идти на обдуманный риск. В высокоэффективных DevOps-организациях, таких как ваша, ошибки случаются чаще. Это нормально и необходимо организации, чтобы учиться и улучшать результаты.
У высокоэффективных организаций на 80% меньше критических сбоев в рабочих системах, чем у обычных. Иными словами, у них в 5 раз меньше инцидентов, затрагивающих клиентов. Поэтому инженерам DevOps важно иметь возможность ошибаться и учиться на своих ошибках.
