SSL-сертификаты просрочены на 4 серверах: как автоматический мониторинг спас нас от даунтайма

Февраль 2026 года. Пятница, примерно 10 утра. Я сижу с кофе, просматриваю дашборд своей инфраструктуры — CosDevDirector, который мы пишем уже несколько месяцев. И тут в блоке мониторинга сайтов вижу жёлтые цифры напротив четырёх записей: 7 дней, 7 дней, 7 дней, 6 дней. SSL Expiry. Семь дней до того, как четыре рабочих сервиса покажут пользователям пугающее красное предупреждение в браузере.

Честно говоря, первая реакция была — "ну окей, успею разобраться". Но потом я открыл пятую запись — cos-supabase.ru — и там было уже другое: красный значок, статус "SSL Error", и 0 дней. Сертификат просрочен. Сайт уже не работает нормально. Вот тут я поставил кофе и начал разбираться.

Рассказываю эту историю не для того, чтобы похвастаться, как круто у меня всё устроено. А потому что в ней есть важный урок, который я хочу донести до всех, кто управляет хотя бы парой серверов. SSL-мониторинг — это не "nice to have", не опция для корпораций с большими бюджетами, не то, что "потом настроим когда дойдут руки". Это базовая гигиена. И вот почему.

Чтобы понять всю картину, нужно немного предыстории. У нас около пятнадцати серверов разного назначения — сайты клиентов, внутренние инструменты, почта, чат, мониторинг, CRM-интеграции. На всех HTTPS, на всех Let's Encrypt, на всех certbot. Стандартная история для любой небольшой IT-команды в 2026 году.

Let's Encrypt работает по простому принципу: сертификат живёт 90 дней, certbot настраивается на автообновление (обычно через systemd timer или cron), и в теории всё происходит само. Ты один раз настроил — и забыл. И это правда работает. Годами. Пока не перестаёт.

Проблема, с которой мы столкнулись, классическая, но не очевидная с первого взгляда. Когда серверы изначально настраивались — на некоторых из них certbot устанавливался и конфигурировался раньше, чем Nginx. Логика простая: сначала получи сертификат, потом настрой веб-сервер. Для получения сертификата certbot использовал `authenticator=standalone` — то есть поднимал собственный мини-сервер на 80-м порту, проходил HTTP-01 challenge от Let's Encrypt и получал сертификат. Работало прекрасно.

Потом приходил Nginx, занимал 80-й порт, начинал слушать и проксировать трафик. А запись в конфиге certbot оставалась прежней — `authenticator=standalone`. Что происходило при следующей попытке обновления? Certbot пытался поднять свой мини-сервер на 80-м порту. Nginx уже там. Конфликт. Обновление падало с ошибкой. Certbot исправно логировал это падение где-то в `/var/log/letsencrypt/letsencrypt.log`. Никто не смотрел.

И так проходило обновление за обновлением — тихо падало, без алертов, без уведомлений, без каких-либо видимых последствий. До поры до времени. Потому что сертификаты, которые были получены когда-то давно с authenticator=standalone (ещё до Nginx), спокойно работали. Их срок жизни просто тихо убывал.

Вот почему четыре сервера оказались в ситуации "7 дней до катастрофы" примерно одновременно. Они, скорее всего, настраивались в один период, сертификаты получили примерно тогда же, обновления у всех падали тихо — и вот она, синхронная проблема.

Теперь о том, как именно это обнаружилось. CosDevDirector — это мой внутренний дашборд для управления инфраструктурой, который я строю как pet-проект с практическим применением. Один из модулей — Site Monitor. Он каждые 5 минут делает HTTP-запросы ко всем зарегистрированным адресам, проверяет доступность, коды ответов, время отклика. И отдельно — проверяет SSL-сертификат: дата истечения, валидность цепочки, имя хоста.

Для каждого сайта в базе хранится `sslDaysLeft` — количество дней до истечения сертификата. Пороги алертов настроены так: 30 дней — warning (жёлтый), 7 дней — critical (красный), 0 или ошибка — dead (тёмно-красный). Эти пороги я выбрал не случайно: 30 дней дают время разобраться без спешки, 7 дней — это уже "срочно сегодня", а 0 — это уже клиенты видят ошибки.

Технически проверка реализована через Node.js — создаётся TLS-соединение с хостом, из сертификата извлекается поле `valid_to`, вычисляется разница с текущей датой. Это важно: мы не просто делаем HTTP-запрос и смотрим на статус код. Мы именно устанавливаем TLS-рукопожатие и смотрим на сам сертификат. Это позволяет поймать ситуации, когда HTTP-запрос проходит (потому что, например, redirect работает), а сертификат при этом уже невалиден или вот-вот истечёт.

В конкретное утро я увидел четыре сайта на 7 и 6 днях — это critical. И один — cos-supabase.ru — уже с истёкшим сертификатом. Пятый я, честно признаться, прозевал. Скорее всего, алерт на 30-дневный порог пришёл и прошёл незамеченным — я тогда много работал с другими задачами. Но именно поэтому в системе есть несколько уровней: чтобы даже если первый пропустил, второй не промолчал. Это принцип defense in depth — не один барьер, а несколько. Если проскочило через первый, должен остановить второй.

Без мониторинга картина была бы другой. Первыми проблему заметили бы пользователи — те самые, которые открыли бы браузер и увидели "Ваше соединение не защищено. Злоумышленники могут попытаться похитить...". Они бы позвонили или написали. Это в лучшем случае. В худшем — просто ушли бы и решили, что "у них что-то со временем сломалось". B2B-сервисы в этом плане особенно чувствительны: если контрагент видит SSL-ошибку на сайте поставщика — доверие падает моментально.

Представьте: сайт b2bChat — это платформа деловых коммуникаций. SSL-ошибка там — это не просто технический инцидент, это удар по репутации. "У вас сайт с ошибкой SSL, вы вообще серьёзная компания?" — это реальная реакция реальных людей. Восстановить доверие после такого сложнее, чем предотвратить проблему. И вот тут есть тонкий момент, который я хочу подчеркнуть: клиент, который столкнулся с SSL-ошибкой, как правило, не думает "наверное, у них технические проблемы с certbot". Он думает "этот сайт небезопасен". Браузеры очень постарались, чтобы предупреждения выглядели именно так — пугающе. И это создаёт нарратив, который потом очень сложно переломить.

Когда я понял природу проблемы (certbot с authenticator=standalone не может обновить сертификат, пока Nginx занимает 80-й порт), решение оказалось простым. Нужно сменить authenticator на `nginx` — тогда certbot будет взаимодействовать напрямую с конфигом Nginx, временно добавляя в него location для challenge, без необходимости занимать порт 80 самостоятельно.

Команда на каждом сервере примерно такая:

```bash certbot renew --cert-name example.com --authenticator nginx --nginx-server-root /etc/nginx ```

Или, если нужно изменить конфигурацию и потом уже обновить:

```bash certbot reconfigure --cert-name example.com --authenticator nginx certbot renew --force-renewal ```

На четырёх серверах это нужно было сделать последовательно. Зайти по SSH, проверить текущую конфигурацию certbot (в `/etc/letsencrypt/renewal/`), изменить authenticator, запустить обновление, убедиться, что получили новый сертификат, перезапустить Nginx. Примерно 10-15 минут на сервер, если нет сюрпризов.

Алгоритм диагностики на каждом сервере был одинаковый. Смотришь файл `/etc/letsencrypt/renewal/domainname.com.conf` — там строчка `authenticator = standalone`. Меняешь на `authenticator = nginx`. Добавляешь строчку `nginx_server_root = /etc/nginx` если её нет. Запускаешь `certbot renew --force-renewal --cert-name domainname.com`. Смотришь вывод — если видишь "Congratulations, all renewals succeeded" — готово. Перезапускаешь Nginx: `systemctl reload nginx`. Всё. На следующий день можешь проверить, что в дашборде sslDaysLeft обновился до ~89 дней. Это значит, что сертификат свежий и автообновление теперь будет работать нормально.

Но вот что важно: я делал это через SSH-терминал прямо в CosDevDirector. Не открывал отдельные вкладки для каждого сервера, не прыгал между окнами. Зашёл в интерфейс, выбрал сервер из списка, открыл терминал — и вперёд. Это кажется мелочью, но когда у тебя четыре сервера с одинаковой проблемой, централизованный доступ экономит не минуты, а нервы. Особенно когда жмёт время. У меня есть привычка из прошлого опыта — когда инцидент развивается, голова занята диагностикой, и любое переключение контекста (открыть другую вкладку, найти пароль, вспомнить, какой там IP у сервера) стоит внимания. Чем меньше таких переключений — тем быстрее и чище работа.

С cos-supabase.ru было немного сложнее: сертификат уже истёк, Nginx отдавал ошибку, и нужно было сначала разобраться с тем, нет ли чего-то дополнительного, что мешает обновлению. Там тоже оказался authenticator=standalone. Плюс выяснилось, что cron-задача certbot была отключена — кто-то давно это сделал при каком-то дебаге и забыл включить обратно. Два источника проблемы, один сервер. Исправили оба, сертификат обновили, Nginx перезапустили, сайт заработал.

Кстати, именно ситуация с cos-supabase.ru показала ещё одну вещь: когда сертификат уже просрочен, certbot renew работает немного иначе — он не всегда соглашается обновить то, что уже "мертво", особенно если конфигурация сломана. Иногда приходится делать `--force-renewal` явно, иногда — полностью переконфигурировать через `certbot delete` и потом заново `certbot certonly`. Это редкий сценарий, но если вы попали в него — не паникуйте, это решаемо за 20 минут даже с нуля.

Общее время на всё — около часа. Если бы я узнал об этом от клиентов, а не от мониторинга, хаотичного времени ушло бы в разы больше: сначала понять, что случилось, потом приоритизировать (кто сломан сильнее?), потом чинить в условиях, когда "всё горит прямо сейчас". Мониторинг дал мне спокойный час с кофе вместо авральных двух часов под давлением.

Я долго думал, почему тема SSL-мониторинга такая недооценённая. Особенно в небольших компаниях и командах. Мне кажется, дело вот в чём: Let's Encrypt создал иллюзию того, что SSL — это решённая проблема. "Поставил certbot — забыл". И в большинстве случаев это действительно так. Автообновление работает тихо и надёжно. Люди привыкают к тому, что это не требует внимания.

Но "в большинстве случаев" — это не "всегда". Проблемы с certbot бывают разные: порт занят (как у нас), изменилась конфигурация Nginx, сменился IP и DNS не успел обновиться, firewall заблокировал порт 80, истёк таймаут и задача упала без ретрая, кончилось место на диске и certbot не смог записать файл. Каждый из этих сценариев реален, и каждый из них приводит к тому, что автообновление тихо не работает — а вы об этом не знаете.

Причём специфика SSL в том, что проблема нарастает медленно. Диск заканчивается — сервис начинает падать прямо сейчас. База данных упала — API недоступен прямо сейчас. А сертификат просто становится на день старше. За 90 дней до истечения ничего не происходит. За 60 дней — тоже. За 30 — всё ещё ничего. И вот в какой-то момент оказывается, что через неделю клиенты увидят ошибку.

Именно поэтому нужен мониторинг с заблаговременными алертами, а не просто проверка доступности. Проверка доступности скажет тебе "сайт упал" уже после того, как упал. SSL-мониторинг с 30-дневным порогом говорит "у тебя есть месяц, чтобы разобраться, почему автообновление не работает". Это принципиально разные уровни реактивности.

Я встречал ситуации, когда люди узнавали о просроченном сертификате от клиентов. И каждый раз это было неловко. Не потому что проблема сложная — она как раз простая. А потому что это воспринимается как признак того, что за инфраструктурой не следят. "У вас сертификат просрочен уже три дня" — это звучит примерно как "у вас в офисе три дня не убирались". Технически некритично, но репутационно неприятно.

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

Самое базовое — это дата истечения сертификата. Казалось бы, очевидно. Но важна не только дата сама по себе, а количество дней до неё, и это число нужно хранить в базе, обновлять регулярно и сравнивать с порогами. В нашем случае проверка раз в 5 минут — это избыточно для SSL (сертификаты не меняются так часто), но удобно, потому что та же задача проверяет и доступность, и время ответа, и коды. Для SSL можно обойтись и одной проверкой в час — главное, чтобы она была.

Второй уровень — валидность цепочки. Сертификат может быть действующим по сроку, но при этом невалидным: если промежуточный CA не подтверждён, если сертификат самоподписан, если цепочка обрезана. Браузеры это поймают и покажут ошибку даже с "живым" сертификатом. Проверять нужно именно TLS-рукопожатие, а не просто дату.

Третий уровень — соответствие имени хоста. Сертификат может быть выдан на `example.com`, а сервис работает на `api.example.com` без wildcard. Или в какой-то момент кто-то перенастроил Nginx и теперь запрос идёт на другой сертификат. Это ловится автоматически при правильной проверке.

Четвёртый — и это часто упускают — алерты с градацией по severity. Одно дело получить уведомление "у вас 5 дней до истечения" в воскресенье вечером. Другое — получать уведомления с 30-дневного порога в рабочее время. Первый алерт должен быть информационным и не требовать срочных действий. Второй — требовать внимания сегодня. Третий (0 дней или ошибка) — немедленной реакции.

Пятый момент, который я добавил уже после февральской истории — история изменений. Когда сертификат обновился, на сколько дней выдан новый, как менялся sslDaysLeft со временем. Это позволяет увидеть паттерн: если сертификат исправно обновляется каждые 60-80 дней, значит, автообновление работает. Если график показывает монотонное убывание от 90 до 0 без скачков вверх — автообновление сломано, и нужно это исправить ещё до истечения.

Эта история про SSL — на самом деле про более широкую тему, которую я называю "невидимым инфраструктурным долгом". Это такие технические проблемы, которые не проявляются немедленно, не ломают ничего прямо сейчас, но медленно нарастают до момента, когда внезапно всё падает.

SSL-сертификат — классический пример. Но такие же истории случаются с дисками (место кончается постепенно), с базами данных (индексы деградируют со временем), с зависимостями (библиотека без поддержки работает годами, пока не появляется критическая уязвимость), с паролями (срок действия истекает в самый неподходящий момент). Всё это объединяет одно свойство: проблема существует, но не видна, пока не превращается в инцидент.

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

Вот ещё один пример из нашей практики, чуть менее очевидный. У нас есть интеграция с одной сторонней системой через API. В один день API начал возвращать ошибки — не всегда, а примерно в 15% запросов. Сервис работал, данные шли, но с потерями. Если бы я мониторил только "доступность" — ничего бы не заметил. Но мы мониторим коды ответов и считаем процент ошибок. Когда он превысил 10% — пришёл алерт. Оказалось, у них на той стороне проблема с rate limiting и мы немного вышли за квоту. Решилось добавлением throttle на нашей стороне. Без мониторинга мы бы узнали об этом из жалобы пользователя: "у меня данные не обновляются". И потом час потратили бы на выяснение того, где именно теряется.

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

Эта философия кажется мне важной вот по какой причине. В небольшой команде, где один человек отвечает за разработку, инфраструктуру, безопасность и ещё десяток вещей — нельзя держать в голове состояние всего. Физически невозможно. Поэтому нужны системы, которые делают это за тебя и сигнализируют, когда что-то требует внимания. Чем меньше команда, тем важнее автоматизированный мониторинг — парадоксально, но именно так. В крупной компании есть DevOps-инженер, который смотрит на графики Grafana весь рабочий день. В небольшой команде нет такого человека. Значит, инструменты должны работать ещё умнее — не просто показывать данные, а говорить "вот здесь нужно внимание".

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

Возвращусь к пятому серверу — тому, где сертификат уже просрочил. Это отдельная поучительная история.

cos-supabase.ru — это внутренний сервис, который используется как часть нашей инфраструктуры данных. Не публичный сайт с постоянным трафиком, а скорее инструмент для разработки и интеграций. И именно поэтому мы не добавили его в мониторинг сразу. Логика была примерно такая: "это внутреннее, там нет пользователей, сломается — сразу заметим".

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

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

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

Февральская история заставила меня пересмотреть несколько вещей в том, как настроен мониторинг и реакция на алерты.

Первое — я добавил Telegram-уведомления для SSL-алертов на 30-дневный порог. Раньше всё показывалось на дашборде, и я рассчитывал, что буду его регулярно смотреть. Но практика показала: дашборд смотришь, когда уже что-то чинишь или проверяешь. А уведомление приходит, когда ты занят другим, и именно тогда заставляет переключить внимание. Алерт в Telegram на 30 дней — это такая мягкая напоминалка: "вот, посмотри, когда будет время". Алерт на 7 дней — уже "это сегодня".

Второе — я сделал для всех серверов аудит конфигурации certbot. Прошёлся по каждому `/etc/letsencrypt/renewal/`, проверил authenticator, убедился, что он `nginx` или `dns` (в зависимости от ситуации), проверил статус systemd timer. Это заняло пару часов, но теперь я знаю, что автообновление работает везде, где должно работать.

Третье — настроил проверку логов certbot как источник для нашего Unified Log Collector. Теперь раз в час скрипт проверяет `/var/log/letsencrypt/letsencrypt.log` на наличие слова "Error" или "Failed" и пишет в unified log. Если автообновление падает — это попадает в логи, логи попадают в дашборд, и я это вижу. Не через 90 дней, когда сертификат почти истёк, а в тот же день, когда обновление упало.

Четвёртое — добавил healthcheck для самих cron-задач. Certbot, как правило, запускается через systemd timer. Если timer неактивен — это тоже сигнал. Проверяем статус timer через SSH, если `inactive` или `failed` — алерт. Это поймало бы ситуацию с cos-supabase.ru гораздо раньше.

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

Давайте поговорим о деньгах — не в смысле стоимости мониторинга, а в смысле стоимости инцидента, который мониторинг предотвратил.

Если бы четыре сервера ушли в SSL-ошибку в один день — а они бы ушли, потому что все были настроены примерно в одно время и все имели одну и ту же проблему — что бы произошло?

На ShopCorp и Cosinnvest — это сайты с клиентским трафиком. Браузер показывает предупреждение и предлагает "вернуться назад". Большинство пользователей именно это и делают. Не разбираются, не нажимают "подробнее", не "всё равно перейти". Просто закрывают вкладку. Сколько заявок и продаж мы бы потеряли за день до устранения? Не берусь называть точные цифры, но это были бы реальные деньги.

Есть исследования о влиянии SSL-ошибок на конверсию, и цифры там недвусмысленные: более 80% пользователей закрывают страницу при виде предупреждения безопасности. Не "большинство", а подавляющее большинство. Причём среди аудитории B2B этот процент ещё выше — там люди более осторожны с переходом через предупреждения, потому что работают с чужими данными и корпоративными системами. Добавьте к этому то, что часть пользователей, которые пришли из поисковика или по рекламе, просто не вернётся: они запомнят, что сайт "выдавал ошибку безопасности", и в следующий раз выберут другой.

На b2bChat — деловые коммуникации. Там своя специфика: пользователи, скорее всего, написали бы нам напрямую и потребовали объяснений. "Ваш сервис сломан, мы не можем работать". Это и репутационные, и практические потери.

B2B Portal — внутренний инструмент для работы с контрагентами. Там сложнее оценить прямые потери, но если сотрудники не могли работать с системой даже несколько часов — это потерянное рабочее время.

Теперь прибавьте к этому время моего рабочего дня на устранение аварии в аварийном режиме — когда "всё горит" и нужно всё бросить и чинить прямо сейчас. Это стресс, потеря фокуса, переработка. В среднем такой инцидент при плохом раскладе — это полдня или целый день активного разбирательства.

Стоимость мониторинга, который предотвратил всё это? Несколько часов на настройку один раз. Минимальные ресурсы на выполнение проверок раз в 5 минут. Всё.

Соотношение явно в пользу мониторинга. Но почему тогда его откладывают? Думаю, проблема в том, что инцидент — это конкретное событие с понятными последствиями. А мониторинг — это инвестиция в предотвращение того, что "может быть не случится". Психологически людям сложно тратить время на предотвращение гипотетической проблемы, когда есть реальные задачи прямо сейчас. Это называется "bias to the present" — и в IT он убивает инфраструктуры так же методично, как в личных финансах убивает сбережения.

Есть ещё один психологический момент, который я наблюдаю. Когда мониторинг работает и предотвращает проблему — это незаметно. Никакого инцидента нет, значит, и результата как будто нет. "Ну и что, что мониторинг поймал SSL — просто повезло, что вовремя заметил". Мозг не связывает отсутствие инцидента с работой мониторинга так же легко, как связывает наличие инцидента с его отсутствием. Это ловушка: успех мониторинга по определению невидим. Он проявляется не в том, что произошло, а в том, что не произошло. И ценить это сложнее, чем ценить инструмент, который "вот, сделал что-то конкретное".

Я долго формулировал для себя, что именно изменила эта февральская история в моём подходе к инфраструктуре. И пришёл вот к какой мысли.

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

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

Я строю CosDevDirector с этой философией в основе. Не как набор инструментов управления, а как систему, которая позволяет видеть инфраструктуру целиком и замечать слабые места до того, как они становятся инцидентами. Дашборд с цветовым кодированием, алерты с градацией, история метрик — всё это инструменты не управления, а видимости.

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

Если у вас сейчас нет SSL-мониторинга — добавьте его сегодня. Это не требует дорогих инструментов: даже простой скрипт на bash, который раз в день проверяет дату сертификата через `openssl s_client` и отправляет сообщение в Telegram, если осталось меньше 30 дней — уже лучше, чем ничего. А если вы строите что-то серьёзное — инвестируйте в нормальный мониторинг с историей, алертами и централизованным дашбордом. Потому что SSL — это только одна из десятков вещей, которые нужно отслеживать. И у каждой из них своя кривая нарастания проблемы. Видеть их все одновременно — бесценно.