SRE. Рецепты выживания в продакшне для инженера по надежности

Наталья Савенкова SRE. Рецепты выживания в продакшне для инженера по надежности

Об управлении надежностью

«Управление надежностью похоже на искусство капитана на корабле: предсказываешь штормы, избегаешь подводных камней и сохраняешь хладнокровие в нестандартных ситуациях. Так корабль плывет безопасно и плавно.

Ненадежный корабль не завоюет доверие пользователей и не обеспечит конкурентоспособность компании. Управлять надежностью сервиса – обязанность каждого капитана сервиса и компании».

Александр Тармолов, руководитель отдела разработки международных веб-решений в Яндекс Картах

«Ошибки в коде и проблемы неизбежны. Очень неприятно и стрессово смотреть на то, как после релиза твой сервис постепенно (или моментально) падает. Но еще хуже, когда в этот момент у тебя нет плана действий и ты просто наблюдаешь, не в силах что-то сделать.

Но если к таким ситуациям правильно готовиться – можно заранее понять, что что-то идет не так, и не довести до падения. Либо снизить влияние на пользователей (можно даже так, что они особо ничего не заметят) и быстро все починить (а для этого нужны инструменты, планы действий для таких ситуаций).

Стресс все равно будет, но гораздо лучше рассказывать коллегам байки за бокалом пенного, как мы героически всех спасли, чем ужасы, как лежали часами и потеряли много лояльных пользователей».

Николай Животворев, руководитель клиентской разработки в Okko (в прошлом – Дзен, Яндекс. Эфир, главная Яндекса)

«Управление надежностью начинается не с конкретных процессов или систем, а с построения принципов работы команды разработки. Особенно это проявляется в Data-Driven направлениях, где дата-инженерам куда проще следить только за надежностью напрямую контролируемых ими ETL-процессов, чем за всей системой целиком, включая поставляемые другими отделами данные. Именно выстраивание принципов команды (как мы работаем, как мы считаем неприемлемым работать, как мы контролируем качество работы смежников, какое качество сервиса мы хотим дать своим пользователям) является основой для построения надежного и полезного для компании продукта».

Максим Пчелин, продакт-менеджер аналитической платформы Nebius (в прошлом – Яндекс, Mail.Ru)

«Информационный продукт появляется на свет как ребенок с иммунитетом, заложенным родителем. Но по мере роста и развития иммунитет нужно тренировать, делать прививки в виде учебных встрясок, интегрировать в себя «ДНК» реальных инцидентов и накапливать ресурсы для столкновения с реальным миром во всем его многообразии. И пусть иммунитет не дает 100% защиты от болезней, но “то, что нас не убивает, делает нас сильнее”, и в конечном счете эволюционную гонку выигрывает наиболее подготовленный организм».

Сергей Савенков, руководитель отдела front-end разработки управления развития розничных систем ООО «МерлионТех»

«Если вы не управляете надёжность своего сервиса – значит, нет у вас никакого сервиса.»

Андрей Столбовский, руководитель разработки в AWS (в прошлом – Яндекс, Вконтакте)

1. Сервис без вмешательства не переживает отключение части свитчей в дата-центре – это плохой сервис

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

Деньги:

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

2. Если какую-то процедуру делать страшно – делай ее чаще