[2/3] Надежность и безопасность — это дополнительные опции или фундамент для современных ИТ-систем? (Рубрика Architecture)

Продолжая рассказ о моем выступлении на PHDays, поделюсь оставшейся частью тезисов и материалов. В прошлом посте я закончил рассказом о примерах из западных bigtech компаний, а дальше я хотел рассказать немного о том, как это устроено у нас в Т, а также дать советы как сделать у себя надежность и безопасность фундаментальной частью разработки, а не опцией:)

Ну и начнем мы с того, что у нас внутри компании есть developer ecosystem, которая представлена PaaS платформой Spirit, которая состоит из большого количества составляющих. Но начать надо с принципов, которым ребята следуют при создании платформы

— Повторяемость и прозрачность жизненного цикла кода в рамках процессов поставки. Код проходит одни и те же стадии: написание, сборка, разные формы тестирования, обновление документации, выкатка в среды, контроль качества после выкатки, поддержка и вывод из эксплуатации. Важно, чтобы любой разработчик мог понять, что происходит и какие стадии процесса ему нужно пройти. — Управление кодовой базой и оценка ее качества на всех этапах. Качество кодовой базы — одна из главных характеристик технического продукта. Умение держать его на стабильно высоком уровне — показатель устойчивости и зрелости процессов разработки. — Переход к Inner Source в компании. Переиспользование кода и наработок коллег — большой плюс для компании. Это помогает уменьшить стоимость разработки и увеличить скорость поставки бизнес-фич. Платформа должна помогать шерить код быстро и безболезненно. — Ориентация на результат. Когда у разработчика есть все необходимые инструменты для управления жизненным циклом продукта, это экономит массу времени. Становится проще создавать новые фичи и чинить старые, запускать тесты и многое другое. Мы хотим, чтобы разработчики могли тратить на создание бизнес-фич 80% рабочего времени, не отвлекаясь на рутину и сложности инфраструктуры. В конечном итоге от этого выигрывают пользователи. Составляющие платформы представлены на схеме, но если отмечать некоторые особо важные для надежности и безопасности, то это

• Sage - observability платформа, использующаяся для централизованного сбора и анализа телеметрии всех сервисов компании. Sage обеспечивает прозрачность бизнес-приложений и ИТ-инфраструктуры и помогает поддерживать бесперебойность работы сервисов.
• FineDog - платформа инцидент-менеджмента, которая помогает Т-Банку оперативно выявлять сбои в работе сервисов, сокращать время их устранения и предотвращать повторение одинаковых инцидентов.
• Nestor - copilot для code suggest и чата внутри IDE, а также других инструментов около кода и не только.
• Safeliner - это AI-ассистент по информационнои‌ безопасности для команд разработки, который может работать как внутри шагов CI/CD, так и быть интегрирован в IDE в качестве плагина. Одновремено, надо отметить, что ребята из Spirit активно работают над темой developer experience и они про это рассказывали в докладе "Почему DevEx важен при разработке IDP и как его померить" (я про него рассказывал). Это позволяет им собирать метрики инженерного опыта и определять, а что внутри платформы требует улучшений.

Но это конечно здорово иметь уже зрелую платформу и выстроенные процессы вокруг надежности и безопасности, а что делать если такого в вашей компании нет?

Для изменений надо

• На уровне стратегии компании сделать эти вопросы приоритетными, определиться с понятными целями (и поставить их в OKR), согласовать выделение ресурсов
• На уровне культуры компании сделать так, чтобы security & reliability стали общей ответственностью команд
• На уровне архитектуры и проектирования учитывать эти архитектурные характеристики и использовать лучшие практики
• На уровне процессов они должны быть интегрированы в pipelines (devsecops и shift left)

Ну и все этим надо управлять как большим проектом изменений, используя change mgmt подходы

#SRE #SystemDesign #Software #Architecture #Metrics #SoftwareArchitecture #Engineering