[1/3] Надежность и безопасность — это дополнительные опции или фундамент для современных ИТ-систем? (Рубрика Architecture)
Сегодня я выступаю на конференции Positive Hack Days в Лужниках с заявленной выше темой. А тут я напишу тезисы и дам отсылки к дополнительным источникам
1) Почему стоит обсуждать эти темы сейчас
- Средняя стоимость сбоев растет и сейчас стоит порядка $300k/hour - подробнее в отчете "Hourly Cost of Downtime - ITIC 2024" (вот мой рассказ)
- Средняя стоимость утечек данных растет и стоит примерно $5M/breach - подробнее в отчете "IBM Cost of a Data Breach Report 2024" (вот мой рассказ в 2 частях: 1 и 2)
- Средняя сложность систем растет (облака, микросервисы, быстрые изменения) - все это приводит к тому, что надежность и безопасность обеспечивать становится сложнее 2) Почему это надо обсуждать на уровне системы и процессов (эмерджентность)
- Про это очень хорошо написано в whitepaper “Developer productivity for Humans: Software Quality” от ребят из Google (я уже рассказывал о нем). Суть в том, что для получения качественного продукта надо правильно выстроить процесс (условно, хочешь хорошую колбасу на мясокомбинате, то будь добр выстроить процессы с учетом ISO 9000). Это верно и для разработки и тут мы гонимся за эмерджентными свойствами (хорошая архитектура, надежность, безопасность), то есть за теми свойствами системы в целом, которые не присутствуют ни в одном из ее отдельных компонентов, но возникают в результате взаимодействий и отношений между этими компонентами. Подробнее про эмерджентность рекомендую почитать в Wiki, а также в кинге физика Девида Дойча "The Fabric of Reality: The Science of Parallel Universes" ("Структура реальности"), о которой я писал раньше 3) Подходы к надежности и безопасности
- Надежность популяризировал Google через культуру SRE - есть три ключевые книги: "SRE Book", "SRE Workbook", "Building Secure & Reliable Systems", о которых я уже тоже рассказывал
- Безопасность двигалась в сторону DevSecOps и Security by Design, где первое хорошо раскрывалось в давней книге "Agile Application Security" (я уже рассказывал про нее), то второе хорошо раскрыто в whitepaper "Security by Design at Google", который я тоже разбирал. Суть всей истории, чтобы безопасность сдвигалась влево и была интегрирована в процессы разработки 4) Подходы к архитектуре и проектированию решений
- ATAM (architecture tradeoff analysis method) - хороший подход к проектированию решений от Software Engineering Institute (SEI), который в том или ином виде часто используется при проектировании для снижения рисков. В этом подходе у нас есть целевые функциональные сценарии, сопутствующие им архитектурные характеристики, которые часто влияют друг на друга и нам требуется принимать решения о компромиссах между ними. Вообще, про этот подход есть хороший рассказ в книге "Software Architecture for Busy Developers", про которую я рассказывал. Кроме того для учета рисков часто используют подход с построением матрицы рисков
- А для учета рисков безопасности в дизайне хорошо бы использвать threat modeling. В итоге, у нас из ATAM есть не только функциональные сценарии, что нам надо реализовать в системе, но еще есть из Threat modeling сценарии угроз, которые надо предотврать 5) Case studies от лидеров индустрии
- Google - про него я много рассказывал и в контексте SRE и Secure by Design, но тут разве что добавлю их motto: "Hope is not a strategy", а также вспомню, что для проверки того, что все учтено на этапе проектирования у них есть design review процесс, про который они рассказывали в whitepaper "Improving Design Reviews at Google" (вот мой обзор)
- Netflix сделал ставку на хаос (Chaos Monkey и далее), чтобы обеспечивать resilience своим системам. Подробнее можно почитать книгу "Chaos Engineering", про которую я писал
- Amazon выбрала себе слоган "At Amazon, security is job zero", вот, например, раздел про культуру безопасности на сайте AWS
Продолжение в следующем посте, так как в один все не влезло:)
#SRE #SystemDesign #Software #Architecture #Metrics #SoftwareArchitecture #Engineering