aphlux

Возникла интересная задача.

Давным-давно, еще позапозапрошлым поколением админов, была написана некая система версионированного бэкапа конфигов. Она работала и работает сама по себе очень хорошо, особенно в тех случаях, когда нецелесообразно поднимать cfengine/puppet -- слишком много архитектур, нет достаточной степени унификации, да и проще писать сами конфиги, чем их мета-версии на YAML или еще чем-нибудь.

Это работало до поры до времени, пока количество серверов и бэкапящейся информации не достигло нескольких сотен. После этого все начало чрезвычайно тормозить. Был (судя по всему, на скорую руку) написан некий шедулер, который ограничивал сверху количество одновременно запускающихся бэкапных скриптов. Ограничивал по очень хитрому алгоритму, который не был документирован вообще никак, а лезть в перловый код никому, кроме его автора, не хотелось совершенно

Многочисленные попытки дописать, переписать шедулер, понять, что же на самом деле в нем происходит, закончились ничем. А тем временем машина тормозила все больше и больше. Меня это начало напрягать, но тут я неожиданно ушел в отпуск, получил травму и мне стало все по барабану. Но я выздоровел, вернулся на работу и вспомнил, о чем же думал перед тем, как в отпуск уйти.

Думал же я о том, что если избавиться от всех алгоритмов и запускать скрипт (точнее, позволять ему запуститься) на каждой машине один раз за N попыток, то, играя значением N, можно попробовать решить хотя бы одну из задач: либо избавить машину от чрезмерной нагрузки, либо уменьшить время между срабатыванием скрипта на отдельно взятом сервере до нормального.
Вернувшись на работу, я практически с ходу начал писать этот шедулер. Немного покопавшись в перловой документации (в старом шедулере были fork() и работа с базой, в моем -- исключительно мультиплексирование через select() ) -- я написал первую версию шедулера. Скрипт запускался с вероятностью 2%, и после тестов я решил его ввести в бой.
Боялся я двух вещей. Во-первых, вероятность срабатывания, которая не приведет к катастрофической загрузке машины, могла оказаться КРАЙНЕ МАЛА. А во-вторых, мне казалось, что после того, как 450-480 машин отработают за первые 2-3 часа, запуск на остальных 30-50 растянется на неделю. Еще не добавляло оптимизма то, что крайне важные машины запускали бэкап в обход всех шедулеров, ежеминутно. Избавиться от этого реально, но это следующий этап работы, их все-таки не так много.

После нескольких часов работы и играми с вероятностью (от 3 до 5%) вышло, что оптимальный с точки зрения загрузки машины порог срабатывания -- 3%. Я начал искать формулу, по которой рассчитывается вероятность того, что ВСЕ машины будут забэкаплены в течение суток/недели/..., нашел теорему Лапласа-Муавра, увидел экспоненту в формуле и... решил проверить, стоит ли вообще что-то считать.
Оказалось -- не стоит. Все машины сбэкапились за пять часов. Причем больше половины из них -- в первый час, половина от половины -- за второй, а за пятый час сбэкапилась только одна машина.
Ради очистки совести я написал "подчищалку хвостов" для запуска раз в сутки, но, видимо, она не понадобится.

Конечно, я сделал все совсем не так, как следовало бы. Индетерминизм -- плохо, хаос -- плохо, случайность -- тоже плохо. Скрипт версионирования конфигов должен быть написан по-другому, пытаться сбэкапиться должны только те конфиги, которые изменились (через inotify, fam или что-нибудь такое это можно организовать), но это гораздо более кропотливая, сложная и долгая работа. Судя по тому, что ее никто так и не сделал, в том числе и автор изначальной системы -- более чем сложная и долгая, делать ее для одного usecase, нам в отдел -- нецелесообразно.

Поэтому мне кажется, что этот выход из ситуации оказался очень изящным. Возможно, этот принцип можно применить где-то еще.
30 строк кода на perl, полное отсутствие съедающей процессорное время логики -- разве этого мало?