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

В GitHub для одной из внутренних организаций сделали Evergreen. Раз в квартал приложение открывает задачу со списком внешних участников. Ответственный отмечает тех, кому доступ ещё нужен, и закрывает её.

Неподтверждённые разрешения отзываются. Если ответа нет, после установленного срока отзывается весь доступ из списка. На проверку предусмотрены две недели. Случайный ручной запуск не должен сокращать этот период.

Состояние проверок хранится в JSON-файлах в Git. По истории изменений видно, кто принял решение и что произошло. Отдельный процесс предупреждает о заброшенных репозиториях и затем архивирует их.

Авторы показывают внутреннюю реализацию на GitHub App, Actions и задачах. Этот процесс можно взять за основу для собственной проверки доступов.

Новый практический челлендж — потренируйтесь разбираться в сетевой конфигурации Linux-хостов: находить имена интерфейсов, IP- и MAC-адреса, шлюз по умолчанию, а также определять, какие маршруты сервер использует для доступа к разным адресам.

Работающий под запросил больше памяти, но на узле её нет. Увеличение ресурсов остаётся в состоянии Deferred, хотя сам запрос допустим. Появление свободного узла в кластере не добавляет памяти на текущем.

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

Возможность включается через InPlacePodVerticalScalingSchedulerPreemption. Это экспериментальная функция, её нужно проверять отдельно от уже стабильного изменения ресурсов работающего пода.

Приоритеты здесь влияют на доступность соседних сервисов. До включения проверьте, кого допустимо вытеснять, и что произойдёт с этой нагрузкой после остановки.

Механизм помогает преодолеть нехватку свободной ёмкости на узле. Запрос, превышающий возможности самой машины, он выполнить не сможет.

HashiCorp закрывает HCP Vagrant поэтапно. Создание новых образов и реестров прекращено с 1 октября. Поддержка и обслуживание заканчиваются 2 ноября, работа сервиса — 31 декабря 2026 года.

Проверьте, откуда команда скачивает образы: ссылки в Vagrantfile, задачи CI/CD, скрипты и инструкции для новых сотрудников. Отдельно учтите собственные публичные и закрытые образы и тех, кто от них зависит.

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

После переноса проверьте загрузку нужных версий с чистой машины и из CI. Локальный кеш способен скрыть неработающую ссылку.

Закрытие касается облачного сервиса. Vagrant CLI и исходный код остаются доступны, образы можно размещать на собственном хостинге.

После восстановления сервиса приходится вспоминать, когда начались ошибки, кто предложил откат и почему одну из гипотез отбросили. Часть ответов остаётся в переписке.

В Grafana Cloud IRM сообщения из Slack можно добавлять в хронологию инцидента реакцией с эмодзи робота. Вместе с текстом сохраняются автор и время. Так полезное наблюдение попадает в запись сразу, пока команда ещё разбирается с проблемой.

К записи привязаны оповещения, панели и данные расследования. Grafana Assistant использует этот контекст для гипотез. Участники могут смотреть источники, опровергать предположения и возвращать их на проверку.

Такая история помогает подготовить разбор после инцидента: восстановить последовательность решений и найти пробелы в процессе.

Связи со Slack и другими сервисами нужно настроить заранее. Вывод помощника остаётся гипотезой, которую команда проверяет по данным.

В этом гайде вы разберётесь, как работает conntrack на реальных сценариях Kubernetes-сетей, и поймёте, почему он играет критически важную роль в работе Kubernetes Services, kube-proxy, NAT и DNS-трафика.

Вы узнаете:
- что такое conntrack и зачем он нужен;
- почему Kubernetes Services зависят от него;
- как посмотреть таблицу conntrack;
- что происходит, когда таблица переполняется;
- как диагностировать и устранять исчерпание conntrack в продакшене.