Вчера регистрация проходила за минуту. Сегодня — бесконечная загрузка. В чате пишут: «Мы ничего не трогали». И это, возможно, правда. Именно поэтому фраза «всё работало вчера» в IT пугает больше, чем любая ошибка на экране.
Вчера регистрация проходила за минуту. Сегодня — бесконечная загрузка. В чате пишут: «Мы ничего не трогали». И это, возможно, правда: просто в полночь истёк ключ, о котором все забыли.
Есть фраза, которую в IT слышат чаще, чем «сайт не грузится».
«Но вчера же всё работало».
Её говорят разработчики. Менеджеры. Поддержка. Иногда — сами пользователи, когда не понимают, почему привычная кнопка вдруг перестала нажиматься.
Звучит безобидно. Даже логично. Вчера работало — значит, кто-то что-то сломал сегодня. Найди, что изменилось, — и починишь.
На практике эта фраза часто означает другое: никто не готов к тому, что системы живут не вчерашним днём, а в постоянных изменениях. И именно в этот момент начинается самая неприятная часть — не поиск ошибки, а поиск того, кто «виноват», пока сервис продолжает криво работать.
История, с которой всё началось
Расскажу про случай из своей практики. Без сложных терминов.
У нас был процесс, который люди проходили каждый день: зашли на сайт → нажали «зарегистрироваться» → ввели данные → получили аккаунт. Работал месяцами. Стабильно, привычно, скучно. В IT «скучно» — это комплимент.
Однажды утром в чат начали сыпаться сообщения:
— У меня крутится колёсико и всё.
— Не могу завершить регистрацию.
— У коллеги получилось, у меня нет.
Первая реакция в команде — предсказуемая:
Странно. Вчера же всё работало.
Дальше по классике. Смотрим, что меняли мы. Вроде ничего критичного. Смотрим логи (записи о том, что делала система). Ошибки есть, но не такие, как обычно. Перезапускаем. Не помогло. Проверяем на себе — у части команды работает, у части нет.
Чем дольше тянется расследование, тем громче становится вопрос: кто трогал?
А ответ оказался неудобным.
Нас не трогали — и это хуже
Виновник нашёлся не во «вчерашнем релизе» (выкладке новой версии программы). Не в «мелком фиксе», который кто-то выкатил в обед.
Изменилось другое:
- внешний сервис, который проверяет номер телефона, начал отвечать чуть иначе;
- срок действия одного из ключей доступа истёк ровно в полночь;
- нагрузка утром выросла — не катастрофически, но достаточно, чтобы один узкий участок начал тормозить;
- в тестовой среде всё ещё было «как вчера», а в реальной — уже нет.
То есть формально команда права: вчера работало.
Но сегодня мир чуть сдвинулся — и привычный процесс сломался.
Вот почему эта фраза опасна. Она успокаивает. А надо наоборот — насторожить.
Ещё один классический сценарий: ключи и сертификаты с истекающим сроком.
Пароль к внешнему сервису, токен доступа, SSL-сертификат (та самая «печать доверия», без которой браузер ругается на сайт) — у всего этого есть дата окончания.
Пока срок не вышел — всё работает. Ровно как вчера.
В полночь срок заканчивается — и система, которую никто не трогал, вдруг перестаёт разговаривать с соседями.
Самое обидное: в логах (записях о работе) часто нет красивой ошибки «ключ просрочен». Есть что-то невнятное: «не удалось подключиться», «отказано в доступе», «таймаут». Команда часами ищет «кто что сломал», а виноват календарь.
Почему «вчера работало» не аргумент
Представьте кофейню, где каждое утро один и тот же бариста делает капучино по одному рецепту. Месяцами — идеально.
Однажды зерно привезли с другой обжаркой. Кассовый терминал обновился. Поставщик молока прислал партию с другой жирностью. Электричество в районе на час моргало.
Капучино «вчера был вкусный» — не значит, что сегодня всё то же самое.
В IT так же, только вместо зерна — десятки связанных сервисов, баз данных, внешних API (чужих программ, с которыми ваша система разговаривает), сертификатов, лимитов, настроек.
Вчера работало — значит лишь, что вчера совпали все условия. Сегодня одно условие изменилось. Достаточно одного.
Самое неприятное: «у меня работает»
В тот день была ещё одна фраза, не менее раздражающая:
У меня-то регистрация проходит. Может, у вас что-то с телефоном?
Когда не работает у всех — паникуют быстро, чинят быстро. Когда у части — начинается спор, кто врёт.
А причина может быть совсем не в телефоне:
- вы попали на другую версию сайта;
- ваш оператор связи идёт через другой маршрут;
- вы нажали лишний раз «назад»;
- у вас старая версия приложения;
- вы из другого региона, а там другой сервер.
«Вчера работало» + «у меня работает» = идеальный шторм. Пользователь думает, что с ним что-то не так. Команда думает, что проблема «точечная». Время уходит. Люди нервничают.
Что на самом деле ломается
Извне кажется: нажал кнопку — не сработало. Значит, сломали кнопку.
На деле между нажатием и результатом — цепочка. Как домино.
Вы нажали «Зарегистрироваться».
→ сайт отправил запрос на сервер
→ сервер проверил данные
→ спросил другой сервис: «этот телефон нормальный?»
→ записал в базу
→ отправил вам код
→ показал следующий экран
Любое звено может сказать «стоп». И тогда вы видите только бесконечную загрузку. Не потому что «сайт лёг». А потому что где-то посередине цепочка замерла.
И вчера эта цепочка проходила за секунду. Сегодня — на третьем шаге кто-то задержался.
Почему тесты не спасают
Здесь обычно спрашивают: ну так проверяйте перед выкладкой!
Проверяем. Но тест — это «вчера в лаборатории». А продакшн (рабочая система для реальных людей) — это «сегодня на улице».
Вчера в тесте:
- нагрузка была меньше;
- внешний сервис отвечал по-старому;
- ключи были свежие;
- никто не нажимал кнопку тысячу раз в минуту.
Сегодня в проде — всё то же, плюс реальность.
Поэтому зрелые команды думают не только «как не сломать», но и «что делать, когда всё же сломалось». Быстрый откат. Мониторинг (система, которая сама кричит «что-то не так»). План на случай «вчера работало, сегодня — нет».
Что мы сделали после того утра
После того случая мы изменили не только код. Мы изменили привычки.
Перестали спрашивать «кто трогал».
Начали спрашивать: «что изменилось в системе или вокруг неё?»
Добавили проверки на внешние зависимости.
Не только «наш код ок», но и «соседи отвечают как ожидаем».
Научились быстрее откатываться.
Если непонятно, но горит — сначала вернуть как было, потом разбираться спокойно.
Перестали верить фразе «у меня работает».
Если жалуются пять человек — проблема есть, даже если у десяти в офисе всё ок.
Завели публичный календарь истекающих ключей и сертификатов.
Чтобы «никто ничего не трогал» не превращалось в «а ключ сам умер в полночь, и мы трое суток это искали».
Скучные вещи. Невидимые пользователю. Но именно они решают, будет ли «вчера работало» означать «сегодня тоже будет».
Публичный календарь истекающих ключей — скучная вещь, которая спасает понедельник
После того случая мы завели простую привычку, которая звучит несерьёзно, а работает лучше половины «срочных разборов».
Публичный календарь всего, что истекает.
Не секретный. Не «в голове у одного админа». А обычный календарь, куда внесено:
- когда заканчивается доступ к внешнему сервису;
- когда истекает сертификат на сайт или API;
- когда надо продлить ключи для оплаты, SMS, проверки телефона;
- когда ротируются (планово меняются) пароли для интеграций.
Почему публичный? Потому что «вчера работало» ломается не тогда, когда программист ошибся, а когда срок вышел по расписанию. И если об этом знает только один человек, который в отпуске — снова получите утро с фразой «мы ничего не трогали».
Аналогия простая. Представьте, что у квартиры:
- страховка;
- договор на интернет;
- подписка на домофон;
- срок годности огнетушителя
висит только в голове у одного жильца. Пока он дома — всё ок. Уехал — внезапно «ничего не работает», и никто не понимает почему.
Публичный календарь — это табличка на холодильнике: что, когда, кто продлевает.
Почему это важнее, чем кажется
Истечение предсказуемо.
В отличие от багов. Ключ истекает не «внезапно» — он истекает в назначенный день. Значит, сюрприз можно превратить в задачу в календаре.
Это дешевле инцидента.
Продлить ключ заранее — минуты. Искать, почему «вчера работало», когда полсервиса лежит — часы. Часы поддержки. Часы разработки. Потерянные регистрации. Нервы.
Это снимает миф «кто-то сломал».
Когда видно, что в ночь на воскресенье истёк сертификат, меньше охоты устраивать охоту на ведьм. Больше — спокойно продлить и сделать выводы.
Это не только для «технарей».
В календаре полезно видеть не только SSL, но и:
- договор с провайдером SMS;
- доступ к сервису карт;
- лицензию на библиотеку в коде;
- сертификат для мобильного приложения в магазине.
Всё это тоже «ключи». Просто не все они выглядят как ключ.
Как это выглядит на практике
Без сложных систем. В нормальной команде достаточно:
- Один список — что истекает, дата, за что отвечает, кто владелец.
- Напоминание заранее — не в день истечения, а за 2–4 недели.
- Проверка после продления — короткий тест: «регистрация проходит, оплата проходит».
- Доступность для команды — не в личной записной книжке, а там, где видят те, кто дежурит.
Скучно? Да.
Спасает от «всё работало вчера» в понедельник утром? Тоже да.
Связь с главной мыслью статьи
Фраза «вчера работало» особенно опасна, когда команда не ведёт учёт времени.
Не только время суток. А время жизни доступов.
Система может быть идеальной в коде. Но если ключ умер в полночь, для пользователя это выглядит так же, как если бы программист нажал не ту кнопку: кнопка не работает.
Публичный календарь — способ сказать: «Да, вчера работало. И мы знаем, что завтра перестанет, если не продлить. Это не сюрприз — это план».
Что это значит для обычного человека
Если вы не в IT, вот короткая расшифровка.
Когда сайт «вчера работал, а сегодня нет» — это не всегда некомпетентность.
Иногда система правда никого не трогала. Изменился мир вокруг.
Когда поддержка говорит «у нас всё работает» — это не всегда враньё.
Иногда проблема правда у части людей. Это не значит, что ваша проблема «ненастоящая».
Когда после обновления что-то отваливается — это не всегда «опять сломали».
Иногда обновление просто вскрыло то, что и так было хрупким.
Когда чинят долго — не всегда потому, что «не умеют».
Иногда потому, что ищут не одну сломанную деталь, а то, что изменилось с вчерашнего дня.
Простой тест для себя
В следующий раз, когда приложение глючит, спросите не только «что случилось?», но и:
- Не обновлялось ли что-то недавно? — приложение, телефон, банк, сам сервис.
- Работает ли у других? — не у одного знакомого, а у нескольких.
- Всегда ли ломается или только в одном сценарии? — например, только при оплате, только при регистрации.
- Прошло ли само через время? — иногда команда уже откатила изменения, а вы этого не видите.
- Если сервис резко «умер» без обновления — спросите себя: не истёк ли срок у чего-то невидимого? Доступ, сертификат, подписка, интеграция. Часто «вчера работало» ломается именно по календарю, а не по коду.
Это не «починит» сервис. Но поможет понять: перед вами временный сбой, массовая проблема или что-то локальное.
Почему я запомнил именно эту фразу
Потому что за ней часто прячется ложное чувство безопасности.
«Вчера работало» — как будто система заслужила доверие навсегда. Как старый надёжный чемодан: ездил десять лет, значит, и одиннадцатый пронесёт.
Но IT — не чемодан. Это живой организм, который каждый день меняется: код, нагрузка, правила, интеграции, законы, пользователи.
Опасна не сама фраза. Опасно то, что за ней перестают готовиться к завтрашнему дню.
Итог
«Всё работало вчера» — самая опасная фраза в IT не потому, что она неправда. Часто это правда.
Опасна она потому, что заставляет думать: раз вчера было хорошо, значит, сегодняшний сбой — случайность, чья-то ошибка, «у вас что-то с телефоном».
А на деле вчерашний день уже не вернуть. Сегодня система живёт в других условиях. И хорошая команда не клянётся на вчера — она смотрит, что изменилось сегодня, и как быстро вернуть вам рабочую кнопку.
Для вас это выглядит просто: вчера нажал — сработало. Сегодня нажал — нет.
А за кулисами кто-то как раз пытается понять, почему «вчера» больше не работает как обещание.
И да: иногда «вчера» заканчивается не потому, что кто-то ошибся. А потому что у доступа был вчерашний день — последний. Хорошие команды это знают заранее. Остальные узнают из чата в 9:07 утра.
А у вас было так — вчера всё ок, сегодня вдруг нет? Что это было: сайт, банк, доставка, госуслуги? Напишите в комментариях — посмотрим, насколько эта история узнаваемая.