[SRE] Бюджет ошибок
Прогерам нужны фичи, SRE-инженерам — надёжность.
Фичи делаются — надёжность страдает. Не делаем фичи — бизнес страдает. Вот примерно такое может случиться с каждой командой, когда речь зайдёт о надёжности. Давайте разберём самые популярные трения между командами. А после разберёмся, как работать с этим.
Устойчивость к сбоям 🛡️ Слабая защита — приложение будет нестабильным и уязвимым 🔐 Сильная защита — скорее всего, никто просто не захочет им пользоваться, зато надёжно
Тестирование ⚡ Мало тестируем — получаем нежелательные простои приложения во время сбоев ⏳ Много тестируем — конкуренты обгоняют нас, и мы теряем долю рынка ❓ А ещё: на какой выборке данных нам тестировать? Насколько большой она должна быть?
Релизы новых фич 🚀 Любой релиз — это риск 🛠️ Нужно найти время и ресурсы, чтобы он был безопасным и не приводил к простоям системы
Как можно заметить, везде нужен баланс. Именно этот баланс команды могут вырабатывать сами или прибегнуть к методологии «Бюджетирования ошибок».
Этот метод помогает определить объективный показатель, с которым будут согласны обе стороны.
А о нём в следующем посте расскажу 😉
Ставь лайкосик 👍, дальше — больше, подпишись!
· 11.08.2025
Ну касательно защиты, игнорируя детали реализации, имхо есть два главных принципа: 1. минимизировать площадь атаки (если вообще необходимо пилить онлайн-фичи, но будем честны: в 2025 онлайн-фичи прикручивают ко всему подряд, даже если это активно вредит) и 2. Внедрять двухфакторную аутентификацию По поводу тестирования – зависит от природы приложения, типа если речь о банкинге или медицине, то здесь лучше перебдеть, раз уж речь в обоих случаях по сути о человеческих жизнях и здоровье, наверное инженерные приложухи тоже лучше бы тестировать потщательнее; в остальных случаях имеет смысл использовать подход "сначала выкатить новые фичи юзерам бесплатной версии, и по их жалобам исправлять неотловленные на КуЭй этапе баги". Выборка – не такой сложный вопрос, когда есть контейнеры, если речь не о ручном тестировании. По поводу релизов: если нет дежурных, то в пятницу лучше не релизить 😸
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён
· 11.08.2025
Тут защита чуток в другом плане - защита от сбоев, я все же не ИБ)
Тесты на пользователях - даже бесплатных, ну такое себе, отпугнет от покупки платного функционала. Есть же канарейки, а/б и так далее, лучше их юзать (хотя в тестах я не оч силен)
А если есть дежурные можно зарелизить)?
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 11.08.2025
Ну, я сам работал только на должности DevOps без Sec, но по-моему что девупс, что СРЕ без заботы о безопасности – деньги на ветер, ну или как минимум значительный оверхэд по времени, ибо всё вынуждено проходить дополнительный отдел) Про тесты на юзерах полностью согласен, практика крайне неэтичная как минимум, но фактически, все это делают, ибо в некритичном приложении люди в основном готовы терпеть баги и разбирательства с ними, чем платить, причём обычно за подписку, потому что тут подписка, там подписка – и вся зп ушла в никуда 😸 Ну если есть, кому разбираться с проблемами в выходные, можно и зарелизить – есть же, кому косяками заняться) А вот если нету, то это уже беда: как минимум двое суток у юзеров будет накапливаться гнев по поводу сбоев, могут и вообще приложение удалить и заменить другим, если у него хватает нужных фич, и оно (пока) работает 😸
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 11.08.2025
Да, безопасность правда важна, просто подсветил, что про нее не могу писать, так как не являюсь прям спецом в это 😅
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 12.08.2025
А, ну тут сложно спорить)
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён