Представим бизнес, который предоставляет пользователям какой-то сервис. У него есть IT-инфраструктура, и от её надёжности зависит вполне конкретная вещь: сможет ли клиент воспользоваться тем, за что заплатил.

Один из подходов к обеспечению этой надёжности вы не найдете в книжках, тем не менее он получил широкое применение в реальных компаниях. Он называется ODD или если развернуто, Outage Driven Development. Разработка через инциденты.

Логика простая: прод упадет - разберемся почему, починим, поправим, второй раз на этом месте не споткнемся.

База перестала справляться? Займёмся базой. Закончились ресурсы? Добавим ресурсов. При росте нагрузки обнаружилось узкое место? Сделаем эпик, починим.

Так мы постепенно движемся к стабильности, собирая по дороге грабли. За каждый такой урок платят пользователи: своим временем, сорванными планами и доверием к сервису.

Почему компании так работают?

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

С ростом пользовательской базы все меняется и фокус внимания переносится с функциональности на обеспечение доступности сервиса для пользователей. В предыдущих постах мы уже говорили о цикле развития и роста компаний. Здесь возникает тот же вопрос: успевают ли процессы измениться вслед за ростом бизнеса?

Клиентская база растёт. Сервис становится частью повседневной работы пользователей. Один и тот же сбой затрагивает всё больше людей, а последствия для компании становятся дороже.

Особенно чувствительно отказы бьют по компании при выходе на самоокупаемость и прибыль. Простои могут означать потерянные продажи, репутационные риски, дополнительную нагрузку на поддержку и уход клиентов. Причём репутационные убытки практически никогда не могут быть посчитаны в моменте: сервис уже восстановлен, а доверие к нему продолжает снижаться.

Поэтому с ростом бизнеса работу над надёжностью желательно включать в план заранее.

Какую нагрузку мы ожидаем через несколько месяцев? Где находятся пределы текущей инфраструктуры? Успеем ли мы подготовиться к росту? Что произойдёт при отказе критичного компонента и сколько займёт восстановление?

Ответы на эти вопросы позволяют заранее выделить время, людей и бюджет. Проверить предположения нагрузочными тестами. Подготовить резервирование там, где оно оправданно. Убедиться, что DRP существует и действительно работает.

Все аварии предотвратить невозможно. Но вполне возможно перестать ждать очередного падения, чтобы заняться уже известной проблемой.

Если рост бизнеса есть в плане, подготовка инфраструктуры к этому росту тоже должна быть в плане.

С вас сердечко, если видели такое в жизни!

Что ещё почитать:

Введение в жизненный цикл IT компании этапы и вызовы для бизнеса

Технические вызовы при росте IT компании:
Первый этап: зарождение (Start Up)
Второй этам: ранний рост (Early Growth)
Третий этип: Масштабирование (Scaling)
Четвертый этап: зрелость (Maturity) и упадок (Decline)

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

До встречи!

@downtime_bar