Почему «следующие N запусков» имеют большее значение, чем красивая картинка правила?
Правило расписания — это теория, список следующих запусков — это план, который вы можете согласовать с жизнью: поезд релизов, окно обслуживания, праздники, отключение продаж и конференция, на которой никто не хочет, чтобы задание по обработке данных сбило номер, пока лидер находится на сцене, а это очень специфическая неделя в каждой крупной компании, каждый год, более одного раза. Предварительный просмотр следующих N запусков — это то, как команда платформы и команда продукта договариваются о минутах, а не о флюидах, и это то, как вы избегаете запуска в эксплуатацию и большой партии одновременно, потому что в обоих случаях было установлено одно и то же местное время без трехбуквенного часового пояса, что является классическим рецептом плохого вторника. Бесплатный онлайн-список следующего запуска cron не является идеальным оракулом, дневной свет, паузы и задержки все еще существуют, но это общий календарь, построенный на основе той же строки, которую будет использовать ваша система, и это намного лучше, чем надежда, что человек правильно прочитает пять полей в мостовом вызове с высокими ставками, в то время как чат громкий и камера включена. Боль — это страница, которая технически правильна и практически неверна, потому что задание началось, но не завершилось, очередь была скопирована или блокировка заблокировала второй запуск, а расписание обещало только первый переход, а не сквозной уровень обслуживания, который вы продали клиенту, а это разговор о продукте, скрытый внутри разговора с операторами. Преимущество заключается в ясности намерений: когда он должен срабатывать, когда смотреть, когда ничего больше не планировать и когда быть доступным человеком, что является инструментом планирования для руководителей, а не только для инженеров, поскольку календарь — это общий ресурс, а общие ресурсы нуждаются в общей истине.
Как разумно использовать списки следующих запусков
- Сгенерируйте несколько предстоящих пожаров в том же часовом поясе, который использует система в производстве, а не на ноутбуке перед глазами усталого инженера во время инцидента, если только в вашей политике в письменном виде не указано иное, один раз.
- Сравните этот список с деловыми календарями, известными паузами и любыми внешними событиями, которые должны препятствовать запуску, и закрепите эти подавления в коде или флагах правил, а не в записке в ящике стола.
- Когда одна работа никогда не должна перекрывать другую, не «надейтесь», что минутного перерыва будет достаточно; добавляйте явные блокировки, очереди или единую систему записи для пакета и отслеживайте конфликты с помощью предупреждений, которые может прочитать человек, а не показателей, которыми никто не владеет.