между “давайте подготовимся заранее к чему угодно и будем оберегать наш хрустальный дворец” и “ничего не делаем вообще”. Если вы не делаете систему жизнеобеспечения, не управляете ракетами и прочими критическими системами, то будет достаточно:
– проанализировать систему на предмет основных рисков
– оценить потери в результате реализации рисков
– спроектировать средства защиты
– оценить стоимость их реализации и поддержки
– применить здравый смысл и выбрать, куда потратить свои деньги
8. Рандомизируй учения
В прошлой главе было много слов про важность проверки систем и протоколы проверок. Назовём эти проверки учениями.
У любых учений есть один главный недостаток: они далеки от реальной катастрофы. И второй недостаток: они проводятся по протоколу.
К сожалению, если на учениях выявилась какая-то проблема у какого-то сервиса, то устранение этой проблемы означает только то, что сервис научился переживать сценарий учений. Это вовсе не значит, что если начать отключать что-то в другом порядке, то всё будет хорошо. И уж тем более не значит, что авария будет проходить по сценарию учений.
Вносите разнообразие в учения. Регулярно меняйте протоколы и форматы.
Изменение последовательности действий во время учений повышает шансы того, что отдельные люди и команды действительно понимают лежащие в основе принципы и готовы реагировать на неожиданные ситуации.
Вот несколько способов внести разнообразие:
– Использовать генератор случайных чисел, где это применимо
– Использовать временные вариации: менять время проведения учебных проверок, например, проводить их в разное время суток
– Вместо одного сценария, представить варианты, когда различные компоненты выходят из строя в разном порядке или возникают несколько проблем одновременно
– Замена ролей: менять членов команды ролями во время учений, это не только изменит динамику, но и покажет проблемы в навыках
– Изменение последовательности: менять порядок шагов в сценарии учений, чтобы увидеть, как участники адаптируются, смогут ли они по-прежнему эффективно решать возникающие проблемы, и как будет меняться поведение всей системы
9. Проектируй failover смолоду
Если у сервиса есть хоть какой-то шанс получить статус "должен работать примерно всегда", то лучше на это закладываться пораньше. Сами процессы стоит проектировать реентерабельными – рассчитанными на перезапуск, параллельный запуск и какой угодно другой запуск и работу. Лучше сразу предполагать, что любая часть проекта может выйти из строя, и резервировать её, если без неё нельзя обойтись. Во-первых, оно будет более-менее устойчивым, а во-вторых более горизонтально масштабируемым.
Сделайте визуальную схему всей системы и спроектируйте меры повышения надежности.
Деньги: резервирование
