Архитектура на старте: подготовка к успеху

Александр начинает с возражения самой постановке вопроса: делать архитектуру надёжной стоит не всегда. Системы полезно разложить по классам — mission critical, где за отказ можно потерять лицензию, business critical, где теряются деньги, и внутренние инструменты, где люди просто ждут, пока починят. От класса зависит, сколько компания готова потратить, потому что надёжность — это дублирование, которое реально стоит денег, более высокий класс железа со своими гарантиями и инженеры, умеющие нужные паттерны реализовать. Александр говорит, что часто встречал обратное: про подходы, пришедшие ещё из сетей, вроде балансировщиков, люди не слышали, книжек про сети не читали, про распределённые системы особо не думали — и сделали как сделали. Отсюда же его первый пример: сбой починили, но всё, что накопилось за время простоя, прилетает разом и укладывает систему обратно. Это метастабильное состояние, про которое, по его словам, есть отдельные научные работы.

Олег подхватывает: система в первую очередь должна быть разумной. Можно вычитать гору литературы и пройтись по всем типам отказов, но к моменту, когда всё это будет вплетено, система может оказаться уже никому не нужна. Его аналогия — маленькая домашняя булочная: чтобы обезопасить её по всем правилам, нужна банковская дверь на десять тонн, открывающаяся двумя людьми и стоящая больше векового оборота магазина, а обычное стекло, которое разобьёт хулиган, — это принятый риск. Свой пример у него тоже есть: проект, теоретически рассчитанный на миллиард человек, набрал аудиторию в пятьдесят тысяч, и накладные расходы на сверхнадёжность не оправдались. Филипп добавляет, что надёжность — не только про то, что система работает, но и про то, что она работает как надо: данные теряются незаметно, деньги где-то зависают, а репликации бегают и снаружи всё выглядит хорошо. Речь тут, уточняет он, скорее не про мониторинг, а про сверку данных двумя независимыми способами.

Вопрос из чата — чем мерить надёжность — ведущий начинает с доступности и советует посмотреть калькулятор девяток. Олег перечисляет классические метрики: среднее время между инцидентами, время до оповещения команды, время до восстановления, оценку влияния на бизнес и вытекающую отсюда цену простоя, — и напоминает, что меряют их не ради цифр, а чтобы не допускать повторений. Филипп возражает: SLA — метрика результирующая, а не проектная, проектировать надо от RTO и RPO, а для данных — от целостности и возможности заметить её нарушение. Минута простоя в час пик и минута ночью, которую пользователь видит только как часики, формально весят одинаково, а по реальным потерям различаются на порядки. SLA он разводит с SLO: первое — контрактное обязательство с пенальти, второе — то, что команда держит в мониторинге и по чему дежурному прилетает звонок, если обещанные 120 миллисекунд на высоком перцентиле не выдерживаются.

Александр показывает, как это устроено в Т-Банке: во внутренний инструмент заносят контракты по услугам, которые видит пользователь, вплоть до обещания, что 99,9 % запросов завершатся успешно; соблюдение считают по данным общей observability-платформы, а при проблемах заводят инциденты, линкуют их между собой и помечают корневой. Бизнесу при этом отдают отчёт по контрактам, а не рассказ про RTO и RPO. Он же вспоминает выступление о том, как в Google отделяли платформенные инциденты от пользовательских: платформа не отвечает за криво задеплоенную нагрузку клиента. Олег замечает, что на практике при отказе прилетает всем независимо от того, кто ошибся, и чинить приходится кросс-командно. У них, по его словам, своя observability-платформа с несколькими миллиардами событий в секунду на не самом большом железе и внутренний сервис надёжности, где тир удерживается, только если после инцидента закрыть оговорённое число action items. Участник, представляющий небольшие компании, парирует: пока сервисов двадцать или даже двести, хватает странички в Confluence, а коммуникация важнее инструментария.

Важнейшим инструментом Олег называет учения: как бы вы ни рассказывали, как прекрасно поведёте себя в критический момент, отказ лучше воспроизвести под контролем — убедиться, что вы его не переживаете, быстро вернуть выведенные компоненты назад и повторить. Иначе окажется, что за той самой десятитонной дверью петли не выдерживают двух открываний, а стена вываливается. Один из участников вспоминает отключение мастер-ноды PostgreSQL с проверкой переключения на реплики и запуск регулярных учений в Яндексе, когда отключали дата-центр: в первые разы вылезало очень много нового, находились сервисы в одном экземпляре, а через полгода командам это стало рутиной. Александр советует начинать с бумажных учений, потом отключать по чуть-чуть и только потом масштабнее, а хаос-инжиниринг считает следующей ступенью — continuous-практикой против того, что без инцидентов люди забывают, куда бежать. Прочитанный одним из экспертов лет пять назад отчёт страниц на семьдесят заканчивался предупреждением: если проблем на проде и так хватает, сначала научитесь переживать их незаметно.

На вопрос, что изучать инженеру, Филипп советует сначала набить шишки и поймать на своём опыте девяносто процентов стандартных проблем, а паттерны читать потом. Олег дополняет: вернуться к целеполаганию, вспомнить про безопасников и покрывать проект документацией не меньше, чем тестами, — этот техдолг хуже разработческого. Про тестирование он ссылается на доклад коллеги Виталия Гриднева о том, как тестируют их базу данных: по приведённой там статистике около 80 % проблем ловится написанием тестов. Александр возвращает разговор к кубикам: «поставлю Kubernetes с фактором репликации три» — это не магия, надо понимать гарантии узлов, ведь Google именно так собрал GFS, прообраз HDFS, на дешёвых серверах. Надёжность он называет эмерджентным свойством: куска кода, в котором её сделали, просто нет. Филипп закрывает тем, что все всегда врут — вендоры, бизнес, разработчики и эксплуатация, — поэтому копать надо на уровень глубже: проверить базу самому или посмотреть, что пишет о ней Jepsen. В вопросах зала участники добавляют экономику: ручные обходы дорожают вместе с ростом продукта, а коробочному решению приходится считать стоимость владения и вовремя слезать с мёртвой лошади.