Надёжность и безопасность: фундамент или опция?

Проблему Александр предлагает фреймить цифрами. Если своей статистики нет, годятся внешние: исследование IBM, по которому утечка в среднем стоит около пяти миллионов долларов, и опрос, где для 90% ответивших компаний час простоя дороже трёхсот тысяч долларов — причём это не каскадные аварии, а средняя величина. Дальше идут репутация и доверие клиентов, которое для финансовой организации остаётся одним из главных активов, и регуляторы, перед которыми приходится отчитываться за крупные сбои и утечки. «Почему именно сейчас» он объясняет ростом сложности: мультиклауд из собственных дата-центров и облачных нагрузок, бум микросервисов десятилетней давности, переложивший сложность на эксплуатацию, и интернет вещей, из-за которого поверхность атаки огромна. На слайде — граф зависимостей из системы трассировки Jaeger, показанный Uber в инженерном блоге; похожий безумный граф, по его словам примерно 2016 года, есть у Netflix. Защитить такую систему постфактум почти нереально.

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

Под надёжностью индустрия обычно понимает практики SRE — дизайн систем в расчёте на то, что отказы будут: избыточность, деградация, отказоустойчивость. Google популяризирует этот подход лет двадцать, и в T-Bank тоже есть каста SRE-инженеров, хотя надёжностью занимаются и сами команды. С безопасностью история похожая: к DevOps начали добавлять приставки — DevSecOps, DataOps, MLOps, — и вот эти названия Александр не любит, потому что за красивым словом теряется суть. Дальше он разбирает вайтпейпер Google о безопасности by design. Логика простая: код ещё не в основной ветке, код влит, код в проде — и безопасность надо смещать влево, туда, где систему ещё проектируют и пишут. Делается это безопасной экосистемой разработки: практики встроены в языки, библиотеки и компоненты, инженеру выдали «безопасную лопату», а не требование знать про безопасность всё. Второй кубик — безопасные деплои и контроль рантайма на уровне control plane, где безопасники любят вспоминать Zero Trust; третий — устранение типовых уязвимостей в шаблонных приложениях.

Дальше Александр показывает, где в проектировании дыра. Какое-то время он отвечал за то, как в компании устроено собеседование по системному дизайну: кандидату дают упрощённую систему, бизнес-требования и неполный набор атрибутов качества и смотрят, как он дособерёт требования, сбалансирует их и поймёт, что важнее. Это напоминает ему метод анализа архитектуры, придуманный лет двадцать назад, если не больше, в институте программной инженерии Карнеги, — ATAM: бизнес-драйверы, сценарии, атрибуты качества, сравнение и осознанные компромиссы, к которым полезно дописать и риски. Но ни в этом собеседовании, ни в RFC и architecture decision records внутри компании безопасности, по сути, нет: решение проработано на уровне «что делаем и какие нефункциональные требования», а потом приходят ребята из безопасности и вкидывают, о чём никто не подумал. Александр считает, что инженерам в роли архитекторов стоит описывать и то, чего в системе быть не должно, — модели угроз. Иначе бутылочным горлышком становятся перегруженные инженеры безопасности, которые на аудите сами разбираются в чужой архитектуре.

Из больших компаний он начинает с Google: надёжность на масштабе, популяризация SLA, SLO и SLI и отдельная команда, куда берут разработчиков и заставляют автоматизировать эксплуатацию: такое не каждый может себе позволить. К выступлению Александр сделал пост со ссылками, в том числе на свой прежний разбор того, как в Google улучшали процесс архитектурного ревью дизайна. Netflix пошёл другим путём: сервисов очень много, оценить их надёжность сложно, поэтому там занялись хаос-инжинирингом и fault injection прямо внутри своих систем, начав с Chaos Monkey. На российском рынке подход тоже прижился — Александр вспоминает рассказ команды Яндекс Такси на архитектурной конференции, в программном комитете которой он состоит. В Netflix команды инженеров сами отвечают за то, что написали и как это живёт в эксплуатации: когда тебя постоянно проверяют в бою, глупо не закладывать отказы виртуалок, сети и целого дата-центра. У AWS он приводит по-разному воспринимаемый тезис, что безопасность — общая работа, и отчёты для топ-менеджмента, которые есть и в T-Bank.

С 2020 года T-Bank движется от разрозненных инфраструктурных команд к внутренней платформе Spirit. Её принципы — повторяемость и прозрачность жизненного цикла кода, оценки качества на каждом этапе, репозитории открыты по умолчанию, и закрыть их сложнее, чем оставить, фокус на снижении когнитивной нагрузки: знать одинаково глубоко требования, распределённые системы, безопасность и инфраструктуру нереально, поэтому правильный путь должен быть лёгким. Надёжность и безопасность держатся на общей observability-платформе с логами, метриками и трейсами, которую начали делать до моды на импортозамещение и теперь продают: ей пользуется НСПК. Поверх неё — инцидент-менеджмент: сервисы и команды с зависимостями, детекция по SLO, жизненный цикл инцидента, эскалация от команды до технического директора и всей компании, разбор в blameless-культуре, отчёты и корреляция релизов со сбоями. Довольство платформой коллеги мерили сначала через Developer Experience, потом через SPACE, и один из инсайтов: меньше всех довольны жизнью SRE, потому что чаще всех встречают проблемы на проде.