Содержание слайдов

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

   Как строить системы, где reliability и security — не afterthought

2. 2. О чём поговорим

   Что на кону: простой, утечки, доверие

   Эмерджентные свойства систем и процессов

   ATAM, риски и угрозы как architecture process

   Кейсы Google/Netflix/AWS, Spirit и выводы

3. 3. 01. Постановка проблемы

   Что на кону, когда речь о надёжности и безопасности

4. 4. Цена простоя и утечки — конкретные деньги

   Простой и инцидент бьют по доходу, репутации и комплаенсу

5. 5. Сложность создаёт безграничную поверхность атаки

   Hyper-connected: cloud, микросервисы, IoT

   Emergent behavior: баг каскадит в отказ

   Rapid change: сотни деплоев в день

   Threats: атаки чаще и изощрённее

6. 6. 02. Эмерджентные свойства

   Reliability и security — свойства всей системы, а не фичи

7. 7. Качество — многомерное свойство системы

   От процесса и кода к системе и продукту

8. 8. Нельзя купить «модуль надёжности»

   Не plug-and-play — не купишь как продукт

   Whole-system: код, инфра, процессы, люди

   Cross-cutting: пронизывает все слои

   Фундамент, а не «прикрутим потом»

9. 9. Проектируем под отказ

   Резервирование и graceful degradation

   Circuit breaker, bulkhead, backpressure

   SLO на uptime/latency с самого старта

   Chaos-тесты и нагрузка до релиза

10. 10. Дешевле всего чинить на этапе дизайна

    Shift left: чем раньше находим — тем дешевле

11. 11. 03. Архитектурные процессы

    Формализуем анализ: ATAM, риски, угрозы

12. 12. ATAM превращает решения в осознанные trade-offs

    Атрибуты качества → анализ → риски и точки чувствительности

13. 13. Приоритизируем по вероятности × влиянию

    Risk Matrix и FMEA превращают тревоги в данные

14. 14. Моделируем угрозы системно, а не по наитию

    STRIDE, PASTA, DREAD, MITRE ATT&CK и другие

15. 15. 04. Кейсы бигтехов

    Google, Netflix, AWS — как это делают лидеры

16. 16. «Hope is not a strategy»

    Benjamin Treynor Sloss, Google

    SRE и SLO/error budgets по умолчанию

    Design review с секцией reliability/security

    Production Readiness Review до запуска

    Blameless postmortems, культура обучения

17. 17. Устойчивость через хаос

    Chaos Monkey гасит инстансы в проде

    Проектируют, предполагая сбои

    Автономия команд + ответственность

    Redundancy, fallback, load shedding

18. 18. Security is Job Zero

    Werner Vogels, Amazon CTO

    Безопасность — до всех приоритетов

    Encryption и строгий IAM по умолчанию

    Сервис не запускают с известной дырой

    Well-Architected: security + reliability

19. 19. 5 принципов от бигтехов

    Security — ответственность каждого

    Reliability — это фича (SLO, error budgets)

    Design for failure: предполагай поломку

    Лидерство и культура задают тон

    continuous improvement — это путь, а не разовый проект

20. 20. 05. Кейс Т-Технологий

    Платформа Spirit: PaaS, observability, инциденты, DevEx

21. 21. Платформа берёт инфраструктуру на себя

    Единый портал, а под ним — весь жизненный цикл сервиса

22. 22. Логи, метрики и трейсы — в одном контуре

    Единый поисковый движок, алертинг и UI поверх сигналов

23. 23. Инцидент — управляемый жизненный цикл

    От детекции до постмортема и релизов

24. 24. AI-копайлот со встроенным security

    Nestor — AI-ассистент в IDE

    Safeliner подсвечивает уязвимости в коде

    Объяснение + предложенное исправление

    Security-ревью встроено в поток разработки

25. 25. DevEx = поток минус когнитивная нагрузка

    Feedback loops, cognitive load, flow state

26. 26. Продуктивность измеряем по 5 осям

    Satisfaction, Performance, Activity, Communication, Efficiency

27. 27. 06. Рекомендации

    Стратегия, культура, архитектура, DevSecOps

28. 28. Что делать — и чего избегать

    Строить

    Reliability/security — в OKR

    Blameless + security champions

    ATAM, threat modeling, DevSecOps

    Избегать

    Security «потом»

    Нет инцидентов — значит ок

    Это задача отдела ИБ

29. 29. Куда всё движется

    AI в ops: помогает и добавляет риски

    Zero trust как фундамент security

    Serverless/контейнеры меняют resilience

    Регуляторы требуют «secure by design»

30. 30. 07. Ключевые выводы и следующие шаги

    Что запомнить и с чего начать в понедельник

31. 31. Фундамент, а не опция

    Reliability и security — built-in качества

    Работает микс: архитектура + риски + культура

    Учимся у лидеров под свой контекст

    Это путь: угрозы и сложность растут

    строя надёжно и безопасно, мы даём бизнесу двигаться быстрее

32. 32. С чего начать в понедельник

    Assess — оцените текущее состояние

    Quick wins — threat-модель и chaos-тест

    Set targets — SLO для критичных сервисов

    Plan — роадмап 12–18 мес.

33. 33. Спасибо!

    polomodov.tech

    Все слайды и ссылки — в Telegram-канале

    Александр Поломодов, Технический директор и Fellow, Т-Технологии

    @book_cube