DEV Community: Sergey Shinder

Der Rollback ist wichtiger als das Release

Sergey Shinder — Wed, 02 Sep 2026 20:41:22 +0000

Wenn ich ein neues Team betrete und wissen will, wie reif der Umgang mit Deployments ist, stelle ich nicht die Frage, wie schnell sie ausliefern können. Ich frage, wie schnell sie zurückkönnen. Die Antwort auf diese zweite Frage sagt mir alles über den Ernst, mit dem hier gearbeitet wird.

Ein Release nach vorn zu bringen ist die halbe Arbeit, oft sogar die einfachere. Der Code ist getestet, alle sind gespannt, es gibt Aufmerksamkeit. Der Rollback dagegen ist der Moment, in dem etwas brennt, alle nervös sind und niemand mehr klar denkt. Genau deshalb darf der Rollback nicht der Teil sein, den wir dem Zufall überlassen. Er muss der eingeübte, langweilige, verlässliche Teil sein.

Ich habe mir angewöhnt, jeden Deploy-Weg von hinten zu denken. Bevor ich überlege, wie die neue Version live geht, überlege ich, wie ich sie in unter fünf Minuten wieder loswerde, ohne nachzudenken. Wenn ich diese Frage nicht klar beantworten kann, ist das Deployment nicht fertig, egal wie schön die Pipeline aussieht. Ein Release ohne geübten Rückweg ist ein Sprung ohne zu wissen, ob unten Wasser ist.

Automatisierung hilft hier enorm, aber nur, wenn ich ihr wirklich vertraue. Und Vertrauen entsteht nicht durch das Skript, sondern durch Wiederholung. Deshalb übe ich Rollbacks bewusst, auch wenn nichts kaputt ist. Wir spielen es durch, in einem ruhigen Moment, ohne Druck. Wenn der Ernstfall kommt, ist es dann kein Experiment mehr, sondern ein Handgriff, den alle kennen.

Ein zweiter Punkt, der oft vergessen wird: Der Rollback der Anwendung ist einfach, der Rollback der Daten ist es fast nie. Eine Migration, die Spalten löscht, macht den Rückweg unmöglich. Deshalb baue ich Änderungen an der Datenbank so, dass alte und neue Version eine Weile nebeneinander leben können. Erst wird die neue Spalte hinzugefügt, dann läuft der Code, und erst viel später, wenn ich sicher bin, wird Altes entfernt. Diese Trennung nimmt dem Deployment seinen Schrecken.

Schnelligkeit beim Ausliefern beeindruckt in der Präsentation. Ruhe im Ernstfall entscheidet über den Schlaf des Teams. Ich baue lieber für die Ruhe.

– Sergey Shinder

Бюджет помилок навчив мене відпускати

Sergey Shinder — Wed, 02 Sep 2026 20:41:15 +0000

Довго я вважав, що моя робота як інженера надійності — не допустити жодного збою. Ціль була проста й нездійсненна: нуль інцидентів. Кожне падіння я сприймав як особисту поразку. Це виснажувало й, як не дивно, робило систему менш надійною, а не більш. Бо коли ти боїшся будь-якої зміни, ти або морозиш розробку, або тихо накопичуєш ризик.

Усе змінив один концепт — бюджет помилок. Ідея майже дитяча за простотою. Ти визнаєш, що стовідсоткової надійності не існує й вона нікому не потрібна. Ставиш чесну ціль — скажімо, 99.9% доступності. Різниця до сотні — це і є твій бюджет на збої. Не провина, а ресурс. Дозволений обсяг того, що система може бути недоступною, і світ від цього не завалиться.

Це перевернуло мислення. Поки бюджет є — команда сміливо релізиться, експериментує, викочує нове. Ризик оплачений заздалегідь. Бюджет вичерпали — автоматично гальмуємо фічі й вкладаємось у стабільність, поки не відновимо запас. Замість вічної суперечки «розробка хоче швидше, надійність хоче безпечніше» зʼявилось число, з яким не сперечаються. Рішення стало спільним і холоднокровним, а не емоційним.

І головне, чого мене це навчило, — відпускати. Не кожен збій треба героїчно гасити о третій ночі. Якщо впало щось, що не їсть бюджет і не болить користувачу, воно може дочекатись ранку. Мій сон теж ресурс надійності: виснажений інженер приймає гірші рішення, ніж той, що виспався. Стійка команда — це не та, що не спить заради аптайму. Це та, що вміє відрізнити «горить зараз» від «полагодимо вранці».

Тепер надійність для мене — не про ідеальність. Вона про адаптацію. Система буде падати, і люди навколо неї будуть змінюватись, і навантаження стрибатиме непередбачувано. Питання не в тому, як не впасти жодного разу. Питання в тому, як швидко піднятись, скільки болю це завдасть користувачу і чи вистачило в команди сил зробити це спокійно.

Бюджет помилок навчив мене найважчого для інженера — відпускати те, що не варте паніки, і берегти сили на те, що справді горить.

– Sergey Shinder

Автоматизуйте не деплой, а відкат

Sergey Shinder — Wed, 02 Sep 2026 20:36:04 +0000

Коли говорять про автоматизацію релізів, майже завжди мають на увазі шлях уперед: як швидше зібрати, як гладше викотити, як довести деплой одним натиском. Це важливо. Але за роки я зрозумів просту річ: найцінніша автоматизація — не в тому, як швидко ти викотиш, а в тому, як швидко й спокійно ти зможеш повернутись назад.

Логіка проста. Деплой уперед ти робиш у робочий час, свіжий, з планом, з увагою всієї команди. Відкат ти робиш у найгіршу мить — коли вже щось горить, коли на тебе дивляться, коли адреналін заважає думати. Саме цей момент найбільше потребує автоматизації, а на практиці саме він найчастіше лишається ручним і страшним.

Я бачив команди з ідеальним CI/CD уперед і повним хаосом назад. Викотити нову версію — одна кнопка. Відкотити — знайти попередній тег, згадати міграції бази, вручну поправити фіче-флаги, помолитись. У результаті люди боялись відкочуватись. А коли боїшся відкату, ти сидиш і терпиш зламаний реліз, замість того щоб за тридцять секунд повернути робочий. Страх відкату — це прихований податок на кожен деплой.

Тому я став вимірювати релізну зрілість одним питанням: скільки часу й скільки ручних кроків між «щось пішло не так» і «ми знову на попередній робочій версії». Якщо відповідь — хвилини й один-два кроки, команда сміливо релізиться часто. Якщо це півгодини паніки, вона релізиться рідко й великими шматками, а великі релізи — це саме те, що складніше й небезпечніше відкочувати.

Практично це означає кілька речей. Відкат — така сама автоматизована операція, як деплой, з тією самою однією кнопкою. Міграції бази сумісні назад, щоб стара версія коду працювала з новою схемою. Фіче-флаги, щоб вимкнути проблемну поведінку без повного відкату. І здоровий інстинкт: спершу поверни користувачам робочу систему, а вже потім розбирайся, що саме зламалось.

Стійка релізна система — це не та, де ніколи не викочують багів. Баги будуть завжди. Це та, де від зламаного релізу до робочого — тридцять спокійних секунд, а не година страху.

– Sergey Shinder

Інтеграція, яка не падає разом із чужим сервісом

Sergey Shinder — Wed, 02 Sep 2026 20:30:53 +0000

Кожна інтеграція — це обіцянка, яку дає чужа команда й яку ти не контролюєш. Їхній API колись відповість повільно. Колись поверне помилку, якої немає в документації. Колись просто ляже посеред дня. Питання не в тому, чи це станеться, а в тому, чи потягне їхнє падіння за собою й твою систему.

Найпоширеніша помилка, яку я бачу, — синхронний ланцюжок довіри. Твій сервіс кличе чужий, чекає відповіді, тримає з'єднання. Чужий гальмує — твої запити стають в чергу. Черга росте — закінчуються потоки. Потоки закінчились — уже й твій сервіс не відповідає власним клієнтам. Один повільний зовнішній API поклав систему, яка технічно взагалі не ламалась. Це і є каскад: чужа проблема стала твоєю через відсутність межі.

Тому я ставлюсь до кожної зовнішньої залежності як до тимчасово ненадійної. Таймаути — завжди, і короткі, а не «за замовчуванням тридцять секунд». Circuit breaker, щоб перестати гатити в сервіс, який очевидно лежить, і дати йому піднятись. Ретраї з backoff та джитером, а не десять миттєвих повторів, які лише добивають того, хто вже задихається. Ідемпотентні ключі, щоб повтор не створив другого платежу чи другого замовлення.

Окремо — деградація замість падіння. Якщо сервіс рекомендацій лежить, сторінка товару має показатись без рекомендацій, а не з помилкою. Якщо не відповідає система знижок, замовлення оформлюється за повною ціною, а перерахунок іде фоном. Користувач майже завжди пробачить трохи менше функціоналу. Він не пробачить білий екран.

І контракти. Я ніколи не вірю, що чужий API повертає рівно те, що написано в доці. Валідую вхідні дані на своєму боці, ставлюсь до відсутнього поля не як до катастрофи, а як до очікуваного випадку. Версіоную свої API так, щоб мати змогу змінюватись, не ламаючи тих, хто інтегрувався зі мною.

Стійка інтеграція — це не та, де всі сервіси ідеальні. Таких систем не буває. Це та, де падіння одного вузла лишається падінням одного вузла й не перетворюється на падіння всього.

– Sergey Shinder

Метрики, які я перевіряю о третій ночі

Sergey Shinder — Wed, 02 Sep 2026 20:25:40 +0000

Спостережуваність перевіряється не на демо для менеджменту. Вона перевіряється о третій ночі, коли задзвенів пейджер, ти ще напівсонний, і в тебе є десять хвилин, щоб зрозуміти, що горить. Якщо в цей момент дашборди красиві, але не відповідають на питання «що зламано й наскільки погано» — вся ця спостережуваність була декоративною.

Я пройшов через етап, коли ми міряли все. Сотні графіків, десятки дашбордів, метрики на кожен чих. Виглядало солідно. А під час реального інциденту ми гортали ці екрани й не могли знайти головного — де саме почалась деградація і кого вона зачепила. Забагато сигналу — це той самий шум, просто дорожчий.

Тоді я змінив підхід. Спершу питання, потім метрики. Що я хочу знати першим о третій ночі? Скільки користувачів зараз страждає. Який шлях запиту зламався. Чи це наша проблема, чи впав хтось нижче за течією. Кожна метрика має заслужити своє місце тим, що відповідає на одне з таких питань. Не відповідає — вона тільки заважає.

Далі — три речі разом, бо поодинці вони брешуть. Метрики кажуть, що щось не так. Логи кажуть, що саме сталось на конкретному запиті. Трейси кажуть, де в ланцюжку сервісів застряг час. Метрика без трейса — це тривога без адреси. Трейс без метрики — це історія без масштабу. Я хочу за пару кліків пройти шлях від «щось не так» до «ось цей сервіс, ось цей запит, ось цей рядок».

І окремо про алерти. Алерт має означати дію, а не факт. «CPU 80%» — це не інцидент, це погода. «Помилки на оформленні замовлення ростуть пʼять хвилин» — ось за цим варто будити людину. Кожен алерт, який дзвенить і не вимагає нічого робити, повільно вбиває довіру до всієї системи. Через місяць таких сповіщень люди починають ігнорувати пейджер — і пропускають справжній.

Стійка система — це не та, де багато графіків. Це та, де о третій ночі ти за десять хвилин розумієш, що відбувається, і йдеш це лагодити, а не шукати.

– Sergey Shinder

Kubernetes не рятує від того, чого ви не продумали

Sergey Shinder — Wed, 02 Sep 2026 20:20:29 +0000

Kubernetes часто продають як щось, що саме зробить систему стійкою. Мовляв, поставив кластер — і воно саме перезапустить, саме розкладе, саме витримає навантаження. Це небезпечна ілюзія. Kubernetes не робить систему стійкою. Він лише дуже чесно показує, наскільки стійким ти зробив свій застосунок.

Простий приклад. Оркестратор може будь-коли вбити твій под — під час деплою, при перерозподілі навантаження, при виході ноди з ладу. Це не збій, це нормальна робота. Але якщо твій сервіс не вміє чисто завершуватись, не обробляє SIGTERM, кидає клієнтів посеред запиту — Kubernetes просто зробить цю проблему регулярною. Раніше під падав раз на місяць, і ти цього не помічав. Тепер він рухається щодня, і кожен рух — це обірвані запити.

Те саме з probes. Ліміти, readiness, liveness — це не бюрократія з ямл-файлів. Це спосіб сказати кластеру, коли под справді готовий приймати трафік, а коли його треба лишити в спокої. Неправильний liveness-probe перетворює тимчасове гальмування на нескінченний цикл перезапусків. Я бачив системи, які самі себе клали під навантаженням саме через це: сервіс тупив, probe вважав його мертвим, кластер убивав под, навантаження йшло на сусідні — і вони теж падали по черзі.

Мій підхід простий. Kubernetes — це не страховка, а контракт. Він каже: я готовий пересувати, перезапускати й масштабувати твій застосунок будь-коли, але за це ти маєш зробити його таким, що переживає ці рухи. Graceful shutdown. Ідемпотентні операції. Стан не в памʼяті поду, а зовні. Чесні probes. Ліміти ресурсів, щоб один сервіс не зʼїв ноду цілком.

Коли контракт виконано, кластер справді дає стійкість — под падає, а користувач нічого не помічає. Коли контракт порушено, ти отримуєш дорогий і складний спосіб робити ті самі старі помилки, тільки частіше й помітніше. Тому перед тим як хвалити Kubernetes за стійкість, я завжди питаю: а мій застосунок узагалі готовий до того, що його будь-коли переставлять?

– Sergey Shinder

Terraform, який рятує вас у поганий день

Sergey Shinder — Wed, 02 Sep 2026 20:15:19 +0000

Інфраструктуру як код зазвичай продають красивими словами: повторюваність, версійність, ревʼю. Усе правда. Але справжню цінність IaC ти розумієш не в спокійний день, а тоді, коли щось велике падає й треба відновитись швидко, без паніки й без здогадок.

У мене був випадок, коли ми втратили цілий регіон у хмарі. Не окрему машину — весь регіон став недоступним. Роками ми знали б це як катастрофу на кілька діб. Але вся інфраструктура жила в Terraform: мережі, бази, черги, ролі, політики доступу. Ми взяли той самий код, змінили один параметр регіону й почали піднімати все з нуля в іншому місці. Це не було миттєво й не було зовсім без болю, але це було відтворювано.

Різниця ось у чому. Коли інфраструктура зібрана руками через консоль, відновлення — це археологія. Хтось намагається згадати, які саме security groups були відкриті, який розмір диска стояв, чому саме ця версія бази. Кожна така згадка — це шанс на нову помилку під час і без того стресового відновлення. Код цю археологію прибирає. Стан описаний явно, його видно в diff, його можна перечитати спокійно.

Але IaC дає стійкість лише тоді, коли ти йому довіряєш. Якщо половину змін роблять руками повз Terraform, а половину — кодом, ти отримуєш найгірше з двох світів: і drift, і фальшиве відчуття, що все під контролем. Тому в мене жорстке правило: жодних ручних змін у продакшн-інфраструктурі. Треба щось поправити — правиться в коді, проходить plan, проходить ревʼю, застосовується. Навіть якщо це «на пʼять хвилин».

Поганий день настане обовʼязково — регіон, провайдер, помилковий delete, атака. Питання лише в тому, чим ти зустрінеш його: панічним відновленням з памʼяті чи спокійним terraform apply у новому місці. Я обираю друге. Стійкість інфраструктури — це не те, що вона ніколи не падає. Це те, як швидко й передбачувано вона встає назад.

– Sergey Shinder

Пайплайн, який пережив зміну команди

Sergey Shinder — Wed, 02 Sep 2026 20:10:07 +0000

Найкращий тест для CI/CD-пайплайну — це не зелений білд. Це момент, коли половина команди пішла, прийшли нові люди, а пайплайн усе одно працює й ніхто не боїться натиснути кнопку деплою. Саме тоді видно, чи ти будував систему, чи просто збирав купу скриптів, які тримались на одній людині в голові.

У мене був проєкт, де весь реліз знав лише один інженер. Він тримав у пам'яті, який job запускати першим, де підправити змінну, коли ретраїти впалий крок. Поки він був на місці, все летіло. Коли він пішов у відпустку на два тижні, ми не могли викотити навіть хотфікс. Пайплайн формально існував, але фактично його не було — була людина, яку назвали пайплайном.

Ми переписали все з однієї простою вимогою: новий інженер має викотити реліз у перший тиждень, читаючи лише README і дивлячись на самі кроки. Ніяких усних інструкцій. Кожен крок пайплайну сам говорить, що робить і чому падає. Помилки перестали бути «щось зламалось» і стали «ось цей контракт не виконано, ось як полагодити».

Це і є стійкість пайплайну — не кількість стадій і не модні інструменти, а здатність системи пережити зміну людей навколо неї. Команди течуть постійно: хтось приходить, хтось іде, хтось вигорає. Пайплайн, прив'язаний до однієї людини, — це не автоматизація, це відкладений інцидент.

Практично я перевіряю це трьома питаннями. Чи може новачок запустити реліз без мене? Чи зрозуміло з логів, що зламалось, без пошуку по чату? Чи однакова поведінка пайплайну локально й на CI? Якщо хоч одне «ні» — там сидить майбутній збій, просто ще не спрацював.

Я більше не вимірюю CI/CD швидкістю. Я вимірюю його тим, наскільки спокійно система переживає зміни навколо себе. Швидкий пайплайн, який знає лише одна людина, — це ілюзія швидкості. Повільніший, але зрозумілий будь-кому, — це те, на що можна спертись у поганий день.

– Sergey Shinder

Ретроспектива без поиска виноватых спасла нам команду

Sergey Shinder — Wed, 02 Sep 2026 20:10:06 +0000

Крупный инцидент у нас случился из-за одной строчки конфига, которую задеплоил стажёр. Старый рефлекс подсказывал: найти виноватого, отчитать, поставить галочку «разобрались». Мы поступили ровно наоборот, и это оказалось лучшим решением за год.

Вопрос, который мы задали на разборе, был не «кто это сделал», а «как система вообще позволила одной строчке конфига положить прод». И стоило переформулировать — как посыпались настоящие причины. Конфиг применялся без валидации. Не было ревью на изменения продовых настроек. Не было постепенной раскатки, чтобы поймать беду на одном инстансе. Не было быстрого отката. Стажёр просто оказался тем, кто первым нашёл давно вырытую яму.

Вот в чём суть безобвинительной ретроспективы: люди почти никогда не являются корневой причиной. Человек ошибается — это константа мироздания, на неё нельзя закладываться и её нельзя «починить». Чинить надо систему, которая позволила человеческой ошибке дорасти до инцидента. Если решение звучит как «будь внимательнее» — это не решение, это отписка. Внимательнее не станет никто, а грабли останутся лежать.

Из того разбора вышел список конкретных технических действий, а не выговоров. Валидация конфигов в пайплайне до применения. Обязательное ревью на продовые изменения. Постепенная раскатка конфигурации, как у кода. Автоматический откат по метрикам. Каждый пункт закрывал реальную дыру, и каждый делал систему устойчивее к любой будущей ошибке, чьей бы рукой она ни была сделана.

Но был и второй эффект, о котором в SRE говорят реже, а он важнее технического. Стажёр не уволился и не замкнулся. Он остался, и через месяц сам предложил ещё пару улучшений в надёжности, потому что не боялся. Когда за ошибку не казнят, люди перестают их прятать. А спрятанная ошибка — это отложенный инцидент, который рванёт позже и больнее, уже без вашего ведома.

Культура важнее инструментов. Можно накупить лучших систем мониторинга и оркестрации, но если инженеры боятся признаться в ошибке, вы слепы там, где это опаснее всего. Надёжность строится не на безупречных людях, а на системах, которые прощают неизбежные человеческие промахи, и на команде, которая учится вслух, а не шепчется по углам.

– Sergey Shinder

Ночные релизы, от которых мы наконец отказались

Sergey Shinder — Wed, 02 Sep 2026 20:04:55 +0000

Долгое время у нас был культ ночного релиза. Считалось, что выкатываться надо в три часа ночи, когда пользователей мало, чтобы «если что» никто не заметил. На деле это была ловушка, и обошлась она нам дорого — не деньгами, а выгоранием и растянутыми на часы инцидентами.

Проблема ночных релизов не в самом времени, а в том, что они прикрывают плохой процесс. Если ты боишься катить днём при живых пользователях, значит, ты не доверяешь своему деплою. А раз не доверяешь — что-то в нём фундаментально не так. Ночь тут не решение, а анестезия. Сонный инженер в три ночи, поднятый ради отката, ошибается вдвое чаще и чинит вдвое дольше, потому что рядом нет ни коллег, ни ясной головы.

Мы решили лечить причину, а не симптом, и потратили квартал на то, чтобы сделать релизы нестрашными. Первое — автоматизировали выкатку целиком, от кнопки до прогретого прода, без единого ручного шага, который можно забыть или сделать не в том порядке. Ручной релиз всегда содержит человека, а человек в три ночи ненадёжен.

Второе — перешли на постепенную выкатку. Никаких «залили всё сразу и молимся». Новая версия сначала уезжает на маленький процент трафика, мы смотрим на метрики ошибок и latency, и только если всё чисто — раскатываем дальше. Если что-то пошло не так, автоматика откатывает до того, как это заметит большинство. Взрыв радиуса стал крошечным.

Третье, и психологически самое важное — сделали откат тривиальным и быстрым. Одна команда, минута времени, предсказуемый результат. Когда откат надёжен и мгновенен, релиз перестаёт быть прыжком в пропасть. Ты знаешь, что в любой момент можешь вернуться назад, и это меняет всё.

И тогда мы просто перестали катить по ночам. Стали релизиться днём, среди недели, при полном штате и живых пользователях. Да, теперь проблему видно сразу — но именно этого мы и хотим. Ошибка, пойманная за минуту при всех, в сто раз дешевле ошибки, тлеющей до утра.

Хороший релиз-инжиниринг измеряется не героизмом, а скукой. Если выкатка стала настолько рутинной, что её не жалко делать в обеденный перерыв, — вы всё сделали правильно. Ночные релизы — это признак не дисциплины, а страха.

– Sergey Shinder

Ретраи, которые сложили внешний сервис вместо того чтобы спасти

Sergey Shinder — Wed, 02 Sep 2026 19:59:44 +0000

Интеграция с внешним платёжным провайдером однажды преподала мне урок про то, что благие намерения в распределённых системах опаснее всего. У нас была логика ретраев: если запрос к провайдеру не прошёл — повторить. Разумно же? Пока однажды у провайдера не начались подтормаживания, и наши ретраи не превратили лёгкое недомогание в полноценный отказ.

Механика была такая. Провайдер начал отвечать медленно, наши запросы упирались в таймаут, и мы их ретраили. Каждый ретрай — новый запрос поверх уже перегруженного сервиса. Мы, по сути, устроили ему DDoS из лучших побуждений. Он лёг окончательно, а вместе с ним встали все наши платежи. Классический retry storm.

Первое, что мы починили — сами ретраи. Не тупой повтор сразу же, а экспоненциальная задержка с джиттером: каждая следующая попытка ждёт дольше, плюс случайный разброс, чтобы все наши инстансы не долбили провайдера синхронно в одну секунду. И жёсткий лимит на число попыток — три, не бесконечность.

Второе и главное — circuit breaker. Если провайдер стабильно отвечает ошибками, мы перестаём его дёргать вовсе на какое-то время и сразу отдаём управляемую ошибку. Это даёт внешнему сервису шанс встать на ноги, а не добивает его. Пусть лучше часть операций честно отвалится сразу, чем вся система захлебнётся в ожидании.

Третий урок был про идемпотентность, и он оказался тонким. Когда вы ретраите платёж, вы обязаны быть уверены, что не спишете деньги дважды. Мы стали слать в каждый запрос idempotency-ключ, чтобы провайдер понимал: это повтор той же операции, а не новая. Без этого ретраи из спасения превращаются в двойные списания и злых пользователей.

И ещё одно, о чём часто забывают: таймауты. У нас они были выставлены слишком щедро, запрос висел десятки секунд, занимая пул соединений. Пока он висел, приходили новые запросы, и пул исчерпывался — отказ расползался по нашей стороне ещё до внешнего сервиса. Мы ужали таймауты до разумных значений и изолировали пул соединений к провайдеру.

Вывод простой: любой вызов за границу вашего процесса может подвести, зависнуть или подтормаживать. Проектируйте интеграцию не под счастливый путь, а под тот день, когда партнёр по ту сторону API чувствует себя плохо. Ретраи без backoff, breaker и идемпотентности — это не отказоустойчивость, это ускоритель катастрофы.

– Sergey Shinder

Мы тонули в алертах и не видели настоящий пожар

Sergey Shinder — Wed, 02 Sep 2026 19:54:33 +0000

Был период, когда наш дежурный канал в мессенджере выдавал под триста алертов в сутки. Звучит как отличный мониторинг, а на деле это была катастрофа. Когда алертов триста, ни одного из них никто не читает всерьёз. И именно в такой обстановке мы однажды прозевали настоящий инцидент: критичный алерт утонул в потоке шума про то, что диск на тестовой ноде заполнен на 81 процент.

Проблема была не в нехватке мониторинга, а в его переизбытке без смысла. Кто-то навесил алерт на каждую метрику, до которой дотянулся: CPU выше 70, память выше 80, любой всплеск latency, каждый пятисотый код от любого сервиса. Все они срабатывали постоянно, потому что пороги были взяты с потолка, а не из реального поведения системы.

Мы сели и переосмыслили подход целиком. Ключевая идея, которую я теперь повторяю всем: алерт должен звать человека только тогда, когда человек реально нужен и может что-то сделать. Всё остальное — это дашборд, а не пейджер. Высокий CPU сам по себе — не проблема, это просто работающий процессор. Проблема — когда из-за него страдают пользователи.

Поэтому мы перешли на алерты по симптомам, а не по причинам. Не «CPU высокий», а «пользователи получают ошибки» или «время ответа вышло за оговорённый порог». Мы завязали алертинг на SLO: пока бюджет ошибок в норме, система молчит, даже если внутри что-то шумит. Как только сжигание бюджета ускоряется — вот тогда будит человека.

Отдельно навели порядок в трёх столпах наблюдаемости. Метрики отвечают на вопрос «что-то сломалось?». Логи — «что именно?». Трейсы — «где в цепочке сервисов?». Раньше у нас были только метрики и разрозненные логи, и в распределённой системе мы часами гадали, какой из десяти сервисов виноват. Сквозной трейсинг с единым trace-id сократил это до минут.

Итог был почти обидно простым. Мы выключили около двух третей алертов, оставили десяток по-настоящему важных, привязанных к пользовательской боли. И знаете что? Мы стали ловить инциденты быстрее, а не медленнее. Тишина в дежурном канале снова начала что-то значить. Хороший мониторинг — это не когда видно всё, а когда видно главное.

– Sergey Shinder