Инженерия ПО
Engineering Culture в FAANG
Google Project Aristotle изучил 180 команд и обнаружил: самый важный фактор эффективности команды - не состав звёздных инженеров, не технологии, а **психологическая безопасность**. Команды где люди боятся ошибаться - проигрывают командам где ошибки открыто обсуждаются. Engineering culture - это не soft skills, это конкурентное преимущество.
- **Google** обязательно проводит blameless postmortem для всех P1/P2 инцидентов - это часть SRE контракта. Без postmortem нельзя закрыть тикет
- **Etsy** при переходе на blameless culture и частые деплои увеличил количество деплоев с 1 в неделю до 50 в день - инженеры перестали бояться экспериментировать
- **Stripe** публикует некоторые postmortem'ы публично, демонстрируя прозрачность; их engineering ladder доступен в Job Description для каждой позиции
On-Call дежурство
**On-Call** - практика дежурства, при которой инженер несёт ответственность за production в нерабочее время. Google SRE popularized принцип: команда, написавшая код, отвечает за его работу в production. Это создаёт правильные стимулы - инженер, которого будит в 3 ночи, напишет более надёжный код.
**Alert fatigue** - критическая проблема: если алертов слишком много, дежурный начинает их игнорировать. Google правило: on-call инженер должен тратить не более 50% смены на реакцию на инциденты (остальное - улучшение надёжности). Если нарушается - команда добавляет людей в ротацию или уменьшает scope сервиса.
PagerDuty (инструмент алертинга) публикует ежегодный State of Digital Operations: в среднем инженер получает 28 алертов в неделю во время дежурства. Команды с <10 алертами/смену имеют в 2.5 раза более высокий уровень удовлетворённости. Количество алертов - KPI качества мониторинга.
Команда из 4 инженеров решает ввести on-call ротацию. Почему это плохая идея?
Postmortem
**Postmortem** (Post-Incident Review) - структурированный анализ инцидента после его разрешения. Цель - понять root cause и предотвратить повторение, а не найти виноватого. Google SRE ввёл это как обязательную практику для всех P1/P2 инцидентов.
**5 Whys** - техника поиска root cause: "Почему сервис упал?" - Connection pool exhausted. "Почему?" - Pool размер уменьшен. "Почему?" - Изменение без review. "Почему без review?" - Нет обязательного approval для config изменений. "Почему нет approval?" - Процесс не задокументирован. Root cause: отсутствие процесса review конфигурационных изменений.
Stripe публикует postmortem'ы публично - это редкая и ценная практика прозрачности. GitLab опубликовал postmortem после удаления production БД и получил огромное уважение сообщества. Публичные postmortem'ы показывают зрелость инженерной культуры - "мы ошибаемся и учимся".
Postmortem завершён. Action items выявлены. Что является признаком хорошего postmortem?
Blameless Culture
**Blameless Culture** - принцип, что инциденты происходят не из-за "плохих" людей, а из-за системных проблем: неясных процессов, неполного мониторинга, отсутствия тестов. Наказание людей за ошибки приводит к сокрытию проблем; blameless культура - к их решению.
**Психологическая безопасность** (Amy Edmondson, Google Project Aristotle) - важнейший предиктор эффективности команды. Команды с высокой психологической безопасностью быстрее обнаруживают ошибки, охотнее экспериментируют и лучше обучаются. Blameless постмортемы - один из главных инструментов создания психологической безопасности.
Netflix Chaos Engineering построен на blameless принципе: Chaos Monkey случайно убивает сервисы в production в рабочее время. Это невозможно без культуры где сбой - это обучающий опыт, а не повод наказать команду. Toyota Production System (Andon cord) - каждый рабочий может остановить производственную линию при обнаружении дефекта, без страха последствий.
В команде с blameless culture произошёл критический инцидент. Инженер честно рассказал что нажал не ту кнопку. Что делает менеджер?
Engineering Ladder
**Engineering Ladder** (Career Ladder) - система грейдов инженеров, определяющая ожидания по уровню impact'а, самостоятельности и влияния. Это не просто таблица зарплат - это framework для роста и обратной связи.
**Promotion vs Leveling** - важное различие: promotion = когда человек уже работает на следующем уровне и это официально признаётся. Promotion не означает "теперь начнёшь работать как Staff" - это признание что уже работаешь как Staff. Levelcheck работает через конкретные примеры impact'а: не "я хорошо кодирую", а "вот фича которую я спроектировал и доставил, вот 3 инженера которых я mentored".
Basecamp опубликовал свой карьерный ladder публично (basecamp.com/handbook). CircleCI, Rent the Runway, Buffer - тоже. Тренд на прозрачность: когда ladder публичный, меньше субъективности в решениях о promotion и легче новым инженерам понимать ожидания. Dropbox полностью переработал ladder в 2020 году - добавил explicit behavioral anchors для каждого грейда.
Engineering ladder - это HR инструмент для контроля зарплат, не связанный с реальной работой
Engineering ladder - это framework для самооценки, планирования роста и выравнивания ожиданий между инженером и менеджером
Без явного ladder инженеры не понимают что от них ожидается на следующем уровне, менеджеры субъективно решают кого продвигать. Ladder делает implicit explicit: вот поведения и impact уровня Staff - работай над ними целенаправленно. Компании с публичными ladder'ами (Buffer, Basecamp) отмечают меньше конфликтов вокруг promotion и более высокую retention.
Инженер пишет отличный код уже 7 лет и хочет продвижения на Staff уровень. Чего не хватает?
Итоги
- **On-Call** работает только при минимум 8 людях в ротации и строгой гигиене алертов: каждый алерт должен быть actionable, иначе - удалить
- **Postmortem** - это не история инцидента, а конкретные action items с owner'ом и deadline; без них postmortem бесполезен
- **Blameless culture** переводит вопрос с "кто виноват" на "что в системе позволило этому случиться" - это единственный способ системно улучшать надёжность
- **Engineering Ladder** определяет не годы опыта, а scope влияния: задача → компонент → команда → домен → компания
Связанные темы
Engineering culture строится поверх технических практик:
- SRE и Error Budget — On-call, SLO и postmortem - три столпа SRE практики, которые невозможны без blameless культуры
- Техническое лидерство — Tech Lead формирует blameless культуру в команде и является примером для junior инженеров
- Chaos Engineering — Chaos Engineering (Chaos Monkey) работает только в командах с blameless культурой - инцидент в production не должен вызывать страх
Вопросы для размышления
- Как в текущей команде реагируют на ошибки: ищут виноватых или системные причины? Что можно изменить прямо сейчас?
- Есть ли в компании явный engineering ladder? Понятно ли что нужно сделать для продвижения на следующий уровень?
- Если бы on-call дежурство ввели в текущей команде - какие три алерта были бы первыми и почему?