Есть категория аварий, которые особенно обидны. Код не менялся, нагрузка обычная, серверы живы — а сервис недоступен. Причина каждый раз одна из трёх: истёк домен, кто-то поменял DNS-запись, или доступ, который «временно открыли посмотреть», оказался не таким уж временным и через него пришли.
Всё это — не про технологии, а про учёт. Домены, записи и доступы — сущности, которые заводят один раз и больше не трогают, поэтому у них нет владельца, нет истории и нет мониторинга. Разберём, как это чинится.
Домен: самая дешёвая авария из возможных
Начнём с простого. Домен продлевается раз в год, письмо о продлении приходит на почту человека, который его когда-то регистрировал. Дальше сценарии: человек уволился, почта отключена, письмо попало в спам, карта у регистратора протухла. В день X сайт исчезает целиком — вместе с почтой, если MX-записи на том же домене.
Восстановление занимает от часа до нескольких дней, а в худшем случае домен уходит на аукцион и не возвращается никогда. Стоимость проблемы — несопоставима с ценой продления.
Что с этим делать, по убыванию важности.
Первое: соберите список всех доменов компании в одном месте и укажите для каждого регистратора, дату окончания и ответственного. Почти в каждой компании обнаруживается два-три домена, о которых никто не помнил: старый сайт, домен под акцию, домен-опечатка, купленный для редиректа. Они тоже истекают и тоже могут быть перехвачены — а на них могут вести ссылки и почтовые адреса.
Второе: включите автопродление везде, где это возможно, и проверьте, что привязанная карта действующая. Автопродление с истёкшей картой — это иллюзия защиты.
Третье: заведите мониторинг срока. Проверка «сколько дней осталось до истечения» — элементарная операция, но именно она превращает «внезапно всё пропало» в «за 30 дней пришло напоминание».
И четвёртое, организационное: контакты домена должны быть на общий ящик компании, а не на личную почту сотрудника. Это отдельная строка в чек-листе при увольнении, которую все забывают.
DNS: место, где ломается всё и сразу
DNS — это точка, изменение в которой мгновенно отражается на всём сервисе, при этом откатить его нельзя быстрее, чем истечёт TTL. Отсюда правила.
Держите TTL адекватным. Значение в 86400 секунд означает, что после смены записи часть пользователей будет ходить на старый адрес ещё сутки. Для записей, которые вы планируете менять — например, перед переездом сервера, — TTL стоит заранее опустить до пяти-десяти минут, а после переезда вернуть обратно.
Знайте, где вообще живут ваши записи. Типичная ситуация в компании, которая работает больше пяти лет: часть доменов делегирована на NS регистратора, часть — на панель хостинга, часть — на Cloudflare, а один домен непонятно куда, но работает. Разобраться в этом стоит до аварии, а не во время.
Заведите инвентаризацию записей — не ради красоты, а чтобы отвечать на вопрос «что сломается, если этот сервер выключить». Практически всегда обнаруживаются A-записи на серверы, которых уже нет, поддомены под тестовые стенды, забытые CNAME на сторонние сервисы. Каждая такая запись — это либо будущая ошибка, либо, что хуже, вектор для перехвата поддомена: если CNAME ведёт на сервис, где ваш аккаунт уже удалён, кто-то может зарегистрировать его и получить страницу на вашем домене.
Отдельно про почтовые записи. SPF, DKIM и DMARC — это то, из-за чего письма компании уходят в спам, и это единственная область DNS, где ошибка проявляется не мгновенной аварией, а медленным ухудшением. «Наши письма клиенты не получают» — почти всегда история про них.
SSL: не «настроил и забыл»
Про сертификаты сказано много, поэтому только суть.
Автоматическое продление через Let's Encrypt решает девяносто процентов проблемы — но именно девяносто. Оставшиеся десять: сертификат на сервисе, где автоматизация не настроена; сертификат, выпущенный вручную на два года и забытый; сертификат на внутреннем сервисе, к которому не дотягивается ACME-проверка; сертификат, продлившийся успешно, но не подхваченный сервисом, потому что перезапуск не сделали.
Последний случай самый коварный: сертификат в файле новый, а в памяти процесса — старый, и браузер видит просроченный. Проверять поэтому нужно не файл на диске, а то, что реально отдаёт сервер по сети.
Дальше — то же, что с доменами: список всех сертификатов с датами и напоминание за две недели. Плюс проверка полной цепочки: сервер, который не отдаёт промежуточный сертификат, работает в браузере на десктопе и падает в мобильном приложении или при запросе с сервера — это классическая проблема, которую долго ищут.
Доступ к серверам: где рождаются настоящие инциденты
Третий класс проблем — про то, как люди попадают внутрь инфраструктуры.
Типичная эволюция в небольшой компании выглядит так. Сначала админ подключается по SSH со своего компьютера. Потом появляется второй человек, и ключ просто копируют. Потом нужно подключиться к базе с ноутбука — открывают порт 5432 наружу «на время». Потом подрядчику нужен доступ к тестовому стенду — открывают ещё что-то. Через год снаружи торчат порты, о назначении которых никто не помнит, а список тех, у кого есть ключи, никто не вёл.
Дальше сценарий известный: сканеры находят открытый порт СУБД или панель администрирования за пару часов после публикации, брутфорс идёт непрерывно, и рано или поздно одна слабая учётка находится.
Правильная схема простая и не требует дорогих инструментов. Наружу смотрит минимум: веб-порты и SSH. Всё остальное — базы, админки, панели, тестовые стенды — доступно только через VPN. WireGuard настраивается за полчаса, работает быстро и не требует поддержки. Доступ выдаётся персонально: у каждого сотрудника и подрядчика свой ключ, который отзывается одной операцией.
Именно персональность — ключевое отличие от «общего доступа для своих». Общий ключ невозможно отозвать, не сломав работу всем; персональный — отзывается за минуту в день увольнения. И в логах видно, кто именно подключался.
Второй элемент — фаервол по умолчанию закрытый. Не «закроем то, что опасно», а «разрешено только перечисленное». Разница в том, что при первом подходе каждый новый сервис по умолчанию открыт, при втором — по умолчанию закрыт.
Третий — двухфакторная аутентификация на SSH. Ключ плюс одноразовый код. Это чуть менее удобно и радикально снижает риск: украденный ключ сам по себе перестаёт быть достаточным.
Что стоит автоматизировать в первую очередь
Если смотреть по соотношению «польза к трудозатратам», порядок такой.
Мониторинг срока действия доменов и сертификатов. Дёшево, делается за час, закрывает целый класс аварий с полным простоем.
Инвентаризация DNS-записей с регулярной сверкой. Не просто список, а сравнение с тем, что реально отдают серверы имён: расхождение означает, что кто-то менял записи мимо вашего процесса.
Учёт открытых наружу портов с оповещением об изменениях. Новый порт, появившийся на периметре, — это либо ваша работа, либо чужая. Оба варианта стоит замечать в тот же день.
Персональные VPN-доступы вместо общих и вместо открытых портов. Требует больше времени на внедрение, но убирает главный источник риска.
Как это выглядит в COSCIO
В платформе эти три темы сделаны отдельными модулями, но с общей идеей: они не только показывают состояние, но и позволяют его менять из того же места.
Раздел доменов и DNS ведёт список доменов со сроками, показывает записи и умеет их редактировать — при этом работает с тем провайдером, у которого домен реально обслуживается, а не требует переезда на «удобный» сервис. Это принципиальный момент: мы управляем чужой инфраструктурой в том виде, в каком она есть, а не заставляем клиента её перестраивать под нас.
Мониторинг сертификатов проверяет то, что сервер отдаёт по сети, а не файлы на диске, и поднимает инцидент заранее — за столько дней, сколько вы укажете.
Модуль VPN управляет пирами WireGuard: выдача персонального доступа, отзыв, конфиг и QR-код для клиента. Отдельно есть Xray для случаев, когда WireGuard блокируется на уровне сети.
Всё это попадает в ту же ленту инцидентов, что и метрики серверов, — то есть просроченный сертификат приходит тем же путём, что и упавший сервис, а не отдельным письмом, которое можно пропустить.
С чего начать на этой неделе
Соберите три списка. Все домены компании с датами окончания и регистраторами. Все сертификаты с датами. Все порты, открытые наружу на каждом сервере.
Почти гарантирую, что в каждом списке найдётся минимум один сюрприз: домен, о котором забыли, сертификат, который продлевается вручную, и порт, который открыли в прошлом году «на пять минут».
Дальше поставьте напоминания на первые два списка и закройте лишнее из третьего. Это работа на один вечер, которая убирает самые дешёвые и самые обидные аварии — те, где всё сломалось само, потому что никто не смотрел.