Programming's Greatest Mistakes • Mark Rendle • GOTO 2023

Превосходный стендап на тему ошибок в разработке софта, от которого я действительно смеялся. Суть в том, что автор - опытный разработчик софта, который всю дорогу рассказывает про факапы, причем начинает со своего, а дальше раскручивает спираль дальше и упоминает многие известные истории. Давайте я кратко опишу факапы, которые обсуждаются
- The med file Unf*cker - факап автора, где он для устранения бага в повреждении сохраненных файлов сделал софт для их исправления (с интересным неймингом)
- Y2K - проблема 2000 года, когда год должен был помещаться в YY, но в 2000 году надо было перейти к YYYY. И дальше весь софт надо было доработать под эти изменения
- The Kennel club "Dog 38" - забавный пример с хранением чисел в римском формате
- Agile в enterprise в виде SAFe, AutoScrum 1.1 от Accenture и The Agile Landscape v3 от Deloitte - по картинкам видно, что Agile в корпорациях тут зашел куда-то не туда:)
- The Pentium FPU - проблема с плавающей точкой в процессорах Intel, эту ситацию прикольно описал Энди Гроув в книге "Выживают только параноики", про которую я уже писал
- Null - история про появление nullable значений и как там поучаствовал Tony Hoare, который это назвал "Null References: The Billion Dollar Mistake"
- Hartford Center - история про то, что спроектированное в CAD не всегда хорошо чувствует себя в реалььности (тут про обрушение здания из-за снега)
- Knight Capital - эпичная история про high frequency trading и как экстренное обновление программного обеспечения с багом и отключенной защитой от дурака обанкротило за несколько часов большой хедж фонд
- Mariner1 - про баг в формуле, которую транслировали в Fortran, что привело к крушению
- Mars Climate Orbiter - про имперскую и метрическую системы (дюймы и футы) и как из-за этого космический аппарат для исследования Марса вместо того, чтобы исследовать его с орбиты, решил примарсится:)
- Ariane 5 - про то, как при миграции софта с Ariane4 на Ariane5 в 16 битное float поле положили 64 битное значение и к чему это привело
- The Big Rewrite - про факап самого автора
- Javascript - язык, который собрали за 10 дней, а дальше он стал супер-популярным и настолько же неконсистентным:)
- Лейтенант Станислав Петров - как советский офицер предотвратил 26 сентября 1983 года потенциальную ядерную войну после ложного срабатывания системы предупреждения о ракетном нападении со стороны США.

#Fackup #Humor #Reliability #SRE

В этот понедельник мы провели четвертый стрим клуба Code of Architecture по книге "Continuous Architecture in Practice". Он был посвящен в большой степени resilience, но кроме этого мы упомянули про emerging technologies и сделали выводы целиком по книге. Собственно вся дискуссия была вокруг надежности, отказоустойчивости, resilience как архитектурной характеристики. Я уже раньше писал про эту глааву отдельный пост.

У нас в гостях были два гостя:
- Евгений Пешков, техлид, независимый эксперт и консультант, увлеченный созданием продуктов, построением эффективных команд и внедрение практик технического совершенства в мире разработки и архитектуры ПО, основатель сообщества DDDevotion.
- Сергей Баранов, архитектор, основатель конференции ArchDays. Сергей ведет каналы

В рамках обсуждения мы упоминали дополнительные материалы
- Моя статья "Проектируем надежные системы — стоит ли игра свеч", которая целиком посвящена теме надежности
- "Site Reliability Engineering" - книга от ребят из Google, с которой началась серия SRE книг и они рассказывают про процесс в общем
- "Building Secure and Reliable Systems" - книга от ребят из Google, где они рассказывают про принципы проектирования надежных систем (продолжает серию SRE книг)
- "AWS Fault Isolation Boundaries" - интересный white paper от AWS на тему границ изоляции сбоев в AWS (здесь интересно написано про инфраструктурные абстракции: зоны, регионы, globl, а также про разделение control plane и data plane при проектировании сервисов и концепцию static stability)
- "A Model-based, Quality Attribute-guided Architecture Re-Design Process at Google" - интересный white paper от ребят из Google, где показано как редизайнится система для повышения ее надежности, причем сам редизайн выполняется достаточно формально, чтобы по модели оценить позитивное влияние на надежность
- "Deployment Archetypes for Cloud Applications" - интересный white paper от ребят из Google, в котором они рассказывают про разные модели deployment приложений, которые позволяют достигать разных уровней availability (зональный, региональный, мультирегиональный, глобальный, гибридный, мультиоблачный)
- "Philosophy of Software Design" - отличная книга про то, как бороться со сложностью систем
- "503 Подкаст - System Design в разрезе надежности" - подкаст с Андреем Дмитриевым из JUG Ru Group, где я был гостем и мы обсуждали проектирование надежных систем
- "Architecting for Scale: High Availability for Your Growing Applications" - интересная книга Lee Atchison, где он обсуждает проектирование для масштабирования и затрагивает вопросы обеспечения availability. Книга пережила второе издание и это пошло ей на пользу.
- "Собеседование SRE: Troubleshooting и System Design" - моя статья про найм SRE инженеров в Tinkoff, и про тип интервью, в котором мы проверяем на практике работу инженеров в рамках инцидента
- "Публичное интервью по troubleshooting для SRE-инженеров на конференции Devoops" - публичное интервью с разбором инцидента
- Крутой доклад "Паттерны отказоустойчивой архитектуры" ребят из Яндекса про отказоустойчивые системы
- Выступление Сергея Баранова "Как принимать инженерные решения в условиях неопределенности" - упоминали в контексте связи с принципами всей книги "Continuous Architecture"
- Miro доска со всеми нашами слайдами, что мы демонстрировали все 4 серии

#Software #Architect #SystemDesign #Philosophy #SoftwareArchitecture #Processes #Management #SRE #Reliability #DistributedSystems

10 Learnings From Running Production Infrastructure at Google • Christof Leng • GOTO 2023

Хороший доклад от Christof Leng, Lead for Google's SRE Engagement Model and SRE Review Programs. Доклад отлично структурирован и может служить некоторой выжимкой из SRE книг Google, которые доступны на их сайте и про которые я уже рассказывал: SRE Book и Building Secure and Reliable Systems. Если возвращаться к самому докладу, то он состоит из следующих частей

0. Culture - начинается все с знаменитой фразы "Культура ест стратегию на завтрак". Но это еще и инженерная проблема, на которую можно смотреть с точки зрения доступного тулинга, методологии, которую могут использовать инженеры для повышения надежности.
1. Reliability can't be taken for granted - про это же я рассказывал в самом начале своем докладе "Проектируем надежные системы - стоит ли игра свеч", но суть в том, чтобы помнить про надежность и риски того, если система будет недостаточно надежна - на это можно смотреть с точки зрения рисков. Плюс надо помнить, что добавить надежность после создания системы бывает невозможно или слишком дорого, поэтому требования по надежности надо обсуждать в нужный момент
2. Cattle vs. Pets - популярная метафора про то, что нам надо относиться к своим системам не как домашним животным, а как к животным из стада. Это позволяет автоматизировать действия по поддержке стада и масштабировать подходы, что не возможно с домашними животными:)
3. Blamelessness - история про правильный подход к обвинениям. Про это подробнее можно почитать у Веструма, который писал про типологию культур - "A typology of organisational cultures", а также про поток информации в них и отношение к ошибкам - "The study of information flow: A personal journey"
4. Measure what matters - рассказ про SLO (service level objectives) и что они действительно должны быть тем, что важно для пользователей сервиса
5. Failure modes - история про то, что участие в инцидентах в рамках oncall позволяет понять как системы разваливаются, почуствовать пороху и понять, что на кону многое стоит. Это не передается при чтении постмортемов ... даже в слух и по ролям:)
6. No heroes - про то, что культура героев, спасающих всех - это плохо для всех. Нас интересует не преодоление проблем, а их предотвращение.
7. Automation - тут идет речь про посто автоматизацию своей работы, которая позволит делать более сложные задачи и меньше заниматься рутинным ручным трудом - лень двигатель процесса.
8. Change is No. 1 reason for outages - все вокруг постоянно меняется и зачастую это является причиной перебоев в работе. И надо быть готовым к этому. Надо минимизировать риск каждого отдельного изменения и автоматизации их проверки и применения (например, используйте GitOps)
9. Outages are inevitable - проблемы неизбежны и надо быть к ним готовым, ограничивая импакт, частоту и вообще управляя риском.
10. No haunted graveyards - не заводите кладбищ с привидениями, под которыми Chistof понимает важные приложения, которые никто уже не трогает и на знает как они работают, а значит не может починить их в случае проблем с ними.

Напоследок автор говорит, что не надо делать сложные системы. Вместо этого надо стараться делать простые системы, хотя это гораздо сложнее, чем сделать сложную систему:) Автор превозносит simplicity и говорит, что boring is beautiful:)

#Software #Engineering #Architecture #SoftwareArchitecture #SystemDesign #DistributedSystems #SRE #Reliability #Conference

Patterns & Anti-Patterns for Effective Feature Flagging • Edith Harbaugh • YOW! 2019

Интересное выступление от Edith Harbaugh, co-founder и CEO платформы для фича флагов LaunchDarkly. В самом начале Edith вспоминает про темные времена, когда она работала в компании, где релизы были раз в полтора года ... и это было быстро, потому что у конкурента они были каждые три года:) Дальше начинается рассказ про паттерны и анти-паттерны их использования. Но до этого хотелось бы обсудить, что сама идея флагов кажется очень простой: нам надо уметь закрывать часть функциональности в коде флагом, который можно удаленно включить/выключить. Это помогает с несколькими вещами
- С feature flags хорошо работает TBD (trunk based development), а без них почти нет
- Release management становится проще (особенно в мобилках)
- Можно тестировать функциональность на части аудитории, например сотрудниках
Но тут мы оказываемся на стыке двух миров - работы с кодом и релизами и экспериментами (a/b тесты, сегментация пользователей, персонализация, ...)

Ну а дальше давайте я расскажу про какие вещи говорила Edith

Паттеры и хорошие способы применения флагов
- Feature kill switches - паттерны для отключения фичей на случай проблем или на случай спайка нагрузки
- Мердж бранчей без конфликтов - условно feature flag - это enabler для TBD, про который я уже говорил
- Controlled rollout - условно раскатка порции трафика на новую фичу
- Early access betas для самых лояльных/лучших пользователей
- Для блокировки фичей для некоторых пользователей (например, тех, кому нужны только отстоявшиеся фичи)
- Для тестирования в проде и сокращения важности staging контура (Edith предлагает его вообще убить)
- Для подписок, где часть фичей доступна только по подписке (я думаю, что это странный кейс конечно)
- Для отключения старых фичей

Антипаттерны и косяки
- Кривое наименование флагов - это просто путает и мешает использовать флаги
- Overused flags - одни и те же флаги, которые используются разными командами по разному, условно одни думают, что этот флаг лечит от кашля, а другие, что от запора:)
- Конфликтующие флаги - учитывая комбинаторику, конфликтующие очень легко получить, особенно если не подумать заранее о том, что именно мы закрываем флагами
- Использование флагов для критической функциональности, которая уже давно не должна отключаться - пример с CMS системой, где можно флагом было отключить загрузку файлов, что эффективно отключало всю систему:) Смысл в том, что такой флаг уже давно стал бесмыссленным:)
- Флаги, что остаются в коде и никогда не выпиливаются - это просто ухудшает кодовую базу

Напоследок приводятся рекомендации
- Flag carefully
- Lock down access
- Remove flags

P.S.
У нас в компании были разные системы для управления флагами и экспериментами. Сейчас мы идем в сторону общего решения, где
- Базовые сценарии управления флагами будут прямо внутри нашей IDP (internal developer platform) - эта часть про код + release management
- Расширенные сценарии управления будут внутри a/b платформы - это часть про использование флагов для экспериментов, персонализаций, бет и так далее

Если вам нравятся такие задачи и у вас есть опыт промышленной разработки, то вы можете написать мне:)

#Software #Devops #SRE #Reliability #Architecture #Engineering #Processes

Книжный клуб CoA — Recap of "Continuous Architecture in Practice"

Когда я готовил поздравительный пост от нашего клуба, то понял, что не сделал статью с общим саммари по последеней книге, поэтому решил исправиться еще в этом году:) В итоге, в этой статье я хотел поделиться всеми четырьмя выпусками и материалами, которых мы при обсуждении этой книги упоминали очень много:)

Software #Architect #SystemDesign #Philosophy #SoftwareArchitecture #Processes #Management #SRE #Reliability #DistributedSystems

Cultivating Production Excellence • Liz Fong-Jones • YOW! 2019

Еще один доклад про SRE практики от инженера, который получил их работая в Google. Liz Fong-Jones только в начале 2019 года ушла в Honeycomb, а до этого 10 лет работала в Google. Интересно, что новая компания Liz занимается observability инструментами, которые полезны инженерам, заботящимся о надежности своих систем.

Основные тезисы доклада такие
- Production системы становятся все сложнее (особенно при использовании микросервисов и big data) и укратить эту сложность бывает сложно
- Что такое надежность и как ее померить (и что такое uptime)?
- Не стоит покупать DevOps - это не коробки вида Honeycomb, IaaS, K8s, и другие крутые слова. Devops - это пру культуру
- Дальше обсуждение алертов, дашбордов, предсказуемости деплоев, etc
- Возврат от технических систем к социотехническим системам и важность мыслей о людях, кто развивают и поддерживают наши системы
- Лиз предлагает инвестировать в культуру, людей и процессы для того, чтобы повысить надежность систем - и именно это она называет production excellence
- Для повышения production excellence она предлагает целый комплекс мер
- Составить план, опредлиться с метриками и смотреть как они улучшаются
- Вовлекать всех (не только инженеров, но и продактов, финансистов и саппорт)
- Начать Лиз предлагает с того, чтобы научить определять, что что-то с продом идет не так и иметь возможность задебажить эту проблему
- И более сложный совет - это устранить ненужную сложность (но проще сказать, чем сделать):)
- Если системы постоянно ломаются по определенным причинам, то стоит устранить эти причины
- Для измерений Лиз предлагает использовать уже стандартные SLI/SLO/SLA - индикаторы, цели и соглашения по уровню оказания сервисов (это стоит использовать как общий язык с неинженерными специальностями: продактами, финансистами, etc)
- Дальше Лиз объясняет, что для измерения этих показателей надо понимать какие критичные user journeys и дальше думать в разрезе конкретных событий (events)
- И надо уметь определять хорошее событие или плохое (а также фиксировать как успешные, так и неуспешные события - отсюда можно посчитать availabilty) и выставлять thresholds для уровня доступности
- Тут же упоминается проведение chaos экспериментов для определения чувствительности пользователей к уровню сервиса
- Дальше идет речь про то, как понять какое окно использовать для расчета показателей (день, неделя, месяц, etc)
- Важность не упарываться в надежность чрезмерно - важно искать баланс между затратами на надежность и возможностью выделять время на развитие сервиса через добавление новых фич
- Как использовать SLO для генерации alerts и определение error budgets
- Как использовать данные для того, чтобы понимать сколько сейчас требуется тратить времени команды на надежность (совет ориентироваться на бюджет ошибок)
- Помимо SLI & SLO надо еще уметь дебажить проблемы на проде:)
- Для этого надо использовать observability инструменты (кстати, у нас в Tinkoff есть своя observability платформа Sage, которую даже можно потрогать снаружи)
- Дальше Лиз говорит о том, что надо уметь различать почему у нас есть отклонения в показателей работы разных сервисов
- Ну и заканчивается все возвратом к культурным вопросам:
-- что героизм - это не устойчивая стратегия для решения проблем,
-- дебаггинг - это совместная работа, надо тренировать команды работать вместе
-- требуется документировать архитектурные решения и как работают наши системы
-- надо использовать общие инструменты и платформы
-- стоит вести blameless postmortems для инцидентов
- Плюс в конце идет речь про управление рисками - про вероятность и влияние, которые определяют уровень риск. Обычно можно уменьшить вероятность проблем, выбрав те, что влияют на SLO и приоритизировав эти задачи в беклоге. Ну и начать надо с улучшения observability.

P.S.
На тему надежности можно почитать материалы из моего поста "Проектируем надежные системы"

#Software #Engineering #Architecture #SoftwareArchitecture #SystemDesign #DistributedSystems #SRE #Reliability #Conference

Инструменты надежности Такси \ Александр Фишер, Яндекс Такси

Интересное выступление Александра Фишера насчет процессов и инструментов по повышению надежности. Выступление короткое и состоит из шести частей
1. Такси и надежность
Вводная про критичность сервисов такси, профиль нагрузки, кратко про архитектуру, используемые технологии. Дальше про метрики надежности:
- Стандартные: SLO в девятках, MTTR (mean time to recovery)
- Интересные: MTTRC (mean time to root cause) - насколько быстро находится корневая причина сбоя, ROCOF (rate of occurrences of failures) - частотность сбоев
В общем, дальше посыл такой, что в следующих пунктах автор рассказывает про инструменты борьбы со сложностью
2. Хаос
Подход ребят в том, что они используют fault injection, где data plane этого хаоса реализован через lua скрипты для nginx, которые балансируют трафик, а также есть control plane для управления конфигурацией этих инжектированных ошибок. Этот инструмент позволяет
- Замедлять сервис (но укладываясь в propogation deadline)
- Моделировать метастабильное состояние сервиса, когда сервис упал под нагрузкой и встать не может, ждет он кто ему поможет:)
- Выдача 500 ошибок с заданным процентом
3. Срезание нагрузки: деградация, retries, limits
У ребята есть
- Gracefull degradation mode, где неосновной функционал можно отключить (это добавляет 20% мощности, но в планах 50%)
- Управление retries для решения проблемы амплификации запросов во время сбоев
- Есть классификация сервисов по уровням, где уровень зависит от критичности сервиса для возможности выполнить основную функцию (уехать на такси)
4. Виртуальные заказы
Рассказ про тестирование нагрузки на систему через моделирование нагрузки виртуальными заказами, которые позволяют проверить нагрузку не API endpoint, а холистически для всей системы. Крутой инструмент, который решает проблему проверки нелинейных зависимостей и непредсказуемого поведения реально сложной системы в зависимости от разного типа нагрузки.
5. Observability и eventboard
Тут автор показывает и рассказывает про дашборды для observability + интересный eventboard про события на проде, а также кнопку "откатить все за последние n минут", что помогает уменьшить MTTR (mean time to recover) и ускорить восстановление после сбоя.
6. Симуляция инцидентов
Тут идет рассказ про координаторов сбоев + про симуляцию сбоев и тренировки по устранению сбоев, что идут каждую неделю

Ну и в конце выступления автор рассказывает про экспериментальные инструменты
- Autorecovery - робот, что автоматически чинит инциденты (он пока в dry run работает и проходит обкатку)
- SRE GPT - инструмент для помощи в поиске root cause

В общем, мне доклад понравился: интересный рассказ, прикольные мысли, достаточно практичные рекомендации, которые можно использовать и в своих процессах повышения надежности.

#SRE #DistributedSystems #Reliability #Architecture #Software #Processes #Management

Code of Leadership #26 - Interview with Salikh Fakhrutdinov about SRE Growth and SRE Team (Рубрика #Architecture)

В этом эпизоде мы обсудили роль и задачи SRE-инженеров на примере карьеры Салиха Фахрутдинова, главного инженера по надежности в Origination Business Platform Т-Банка. Команда, в которой работает Салих, отвечает за надежность процессов открытия новых продуктов, поддерживает множество сервисов и активно внедряет подход shift left reliability. Салих поделился своим опытом: от первых шагов в программировании до роли главного инженера, рассказал о переходах между компаниями, развитии архитектурных процессов и работе с инфраструктурой. Также обсудили управление командами, дежурства разработчиков, мотивацию для улучшений и важность избыточности в повышении надежности систем.

Мы успели обсудить следующие темы
- Как у Салиха появился интерес к программированию еще во время учебы в школе
- Как он устроился в небольшую компанию и лет за 8 вырос от верстальщика до техдира
- Как Салих искал и нашел себя после прохождения курса для SRE инженеров, а потом перешел в тогда еще Тинькофф
- В чем различие старшего, ведущего и главного инженеров, так как Салих прошел все эти уровни:)
- Как выглядит работа SRE команды, когда дежурит SRE команда, а когда сами разработчики
- Какие стоят цели и задачи перед SRE окмандой
- Что такое shift left reliability и как это делает Салих
- Как использовать избыточность (redundancy) для повышения надежности
- Зачем нужны учения, причем здесь наблюдаемость и где тут архитектура
- В чем различия между менеджерами и инженерами
- Что рекомандует Салих для развития в IT (любите свое дело, учитесь на практике и не бойтесь сложностей!)

🎧 Слушайте выпуск (на podster.fm, Yandex Music), чтобы узнать больше о том, как строить карьеру в IT, развивать навыки SRE и двигать архитектурные процессы.

Полезные материалы
Профиль Салиха на LinkedIn - https://www.linkedin.com/in/free6k
Профиль Салиха в Telegram - https://t.me/free6k
- https://t.me/book_cube/2765
- https://t.me/book_cube/1522
- https://t.me/book_cube/1302

#SRE #Architecture #Reliability #Management #Staff #Engineering #Processes

Интервью с Глебом Михеевым про Individual Contributors, Site Reliability Engineering и надежность

Летом прошлого года мы записали выпуск подкаста "Фичи Катятся" с Глебом Михеевым, автором канала "Уставший техдир" (@tired_glebmikheev). Примерно в это время Глеб поменял работу и занялся AI-ассистентом в Сбере, поэтому снятое отправилось на полку. А сегодня Глеб опубликовал эту запись, где мы с ним много общались про развитие инженеров, проектирование систем, обеспечение их надежности и безопасности. В общем, за час мы успели обсудить много интересных тем. Вообще, мы часто с Глебом встречаемся на разнообразных конференциях и часто такие разговоры получаются очень насыщенными. Рад, что в этот раз мы записали такое общение на камеру:)

Сам выпуск доступен почти везде: ВК, Rutube, Spotify, Apple Podcast.

#Engineering #Software #Reliability #Architecture #Management #Processes #Leadership

2 гига спустя - эпизод первый (Рубрика #News)

Это первый выпуск подкаста с лайтовым обсуждением новостей двумя ведущими Суть в том, чтобы в научпоп формате обсуждать интересные IT новости и выпускать эпизоды раз в неделю. В этом мне помогает Антон Костерин, мой коллега, с которым мы вместе развиваем архитектурную функцию в Т-Банке. Антон входит в программный комитет "Teamlead Conf", а также уже много раз появлялся в моем канале:
- Внешний подкаст с темой "Миграция в срок, реальность или миф?"
- Подкаст "Code of Architecure" в первой серии по книге ван Стина и Таненбаума "Distributed Systems"
- Третий выпуск Code of Architecture по книге "A Philosophy of Software Design"
- Code of leadership #17 - Interview with Anton Kosterin about Architecture

В первом выпуске мы обсудили темы
0) Vibe coding в обсуждении Y Combinator. Где vibe coding становится новым подходом к программированию, позволяющим быстро создавать код с помощью ассистентов без необходимости глубокого изучения программирования, что особенно полезно для стартапов и домашних проектов. Оригинальное видео и мой краткий разбор
1) Forbes написали о том, что 95% объектов критической инфраструктуры используют зарубежные решения, включая Zabbix для мониторинга (85%), что поднимает вопросы импортозамещения
2) Ситибанк допустил серьезную ошибку, случайно переведя 81 триллион долларов вместо 280 тысяч, что подчеркивает необходимость многоуровневой защиты в финансовых системах.
3) C++ сталкивается не только с проблемами безопасности, но и с проблемами маркетинга, что может привести к его упадку, несмотря на то, что он остается стандартом де-факто в индустрии. Об этом рассказал сам создатель языка, Бьерн Страуструп
4) Равинд Шинивас, CEO Perplexity, поделился своим опытом создания компании, разрабатывающей AI поиск с использованием LLM моделей и успешно конкурирует с Google Search, Microsoft Bing и остальными. Оригинальное видео и мой разбор
5) Исследование показало, что внешность кандидата может влиять на успешность прохождения интервью, что поднимает этические вопросы при найме. Нейронные сети могут перенимать человеческие предубеждения из обучающих данных, что особенно проблематично в таких областях как медицина, где важна точность прогнозов.

Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music.

#Management #AI #Software #Engineering #Reliability #Processes #Productivity