#люди
Джеф Безос однажды сказал: "Хорошие намерения не работают, вам нужны хорошие механизмы чтобы что-то произошло."
Методология SRE включает в себя так называемый пост-мортем - разбор полетов после инцидента. Разные конторы делают это по-своему, но основная задача проста как мир: не допустить такого же инцидента снова.
Один из вопросов, на который мне, после одного инцидента, пришлось ответить: "Что можно было сделать, чтобы избежать этого инцидента?" Я честно ответил, что мне не хватило того и этого, да и в принципе, потрать я больше времени и проверь все раз десять, то не накосячил бы так... за что получил нагоняй от наставника.
Результатом пост-мортема являются одна или более задачи, результатами которых должны быть артефакты:
• Не смог понять, что именно упало - нужны понятные логи и метрики, дашборды и инструменты observability
• Отказ одной системы вызвал цепную реакцию и retry storm - circuit breaker
• Получил уведомление, но не знал что делать - нужны понятные runbook'и и механизмы эскалации
Я же в свою очередь уперся в личностное и посчитал, что во избежание инцидента нужно крепенько думать, что делаешь. После чего, мой старший коллега процитировал экс-главу Amazon и объяснил, что мы тут все умные и внимательные котики, но так и будем косячить без полезных инструментов. Не сегодня, так завтра. Не я, так кто-нибудь другой.
И если так подумать, то все инструменты, которые любезно делает ваша группа DevExp (если она у вас есть, конечно): кодогенерация, IDL, герметичная сборка, монорепы и т.д. - это не только ускоряет работу кожаного мешка, сидящего на неприемлемо большой зарплате, но и уменьшает вероятность аварии категории PEBCAC.
Джеф Безос однажды сказал: "Хорошие намерения не работают, вам нужны хорошие механизмы чтобы что-то произошло."
Методология SRE включает в себя так называемый пост-мортем - разбор полетов после инцидента. Разные конторы делают это по-своему, но основная задача проста как мир: не допустить такого же инцидента снова.
Один из вопросов, на который мне, после одного инцидента, пришлось ответить: "Что можно было сделать, чтобы избежать этого инцидента?" Я честно ответил, что мне не хватило того и этого, да и в принципе, потрать я больше времени и проверь все раз десять, то не накосячил бы так... за что получил нагоняй от наставника.
Результатом пост-мортема являются одна или более задачи, результатами которых должны быть артефакты:
• Не смог понять, что именно упало - нужны понятные логи и метрики, дашборды и инструменты observability
• Отказ одной системы вызвал цепную реакцию и retry storm - circuit breaker
• Получил уведомление, но не знал что делать - нужны понятные runbook'и и механизмы эскалации
Я же в свою очередь уперся в личностное и посчитал, что во избежание инцидента нужно крепенько думать, что делаешь. После чего, мой старший коллега процитировал экс-главу Amazon и объяснил, что мы тут все умные и внимательные котики, но так и будем косячить без полезных инструментов. Не сегодня, так завтра. Не я, так кто-нибудь другой.
И если так подумать, то все инструменты, которые любезно делает ваша группа DevExp (если она у вас есть, конечно): кодогенерация, IDL, герметичная сборка, монорепы и т.д. - это не только ускоряет работу кожаного мешка, сидящего на неприемлемо большой зарплате, но и уменьшает вероятность аварии категории PEBCAC.
