Автор:  root

2015-08-03: Законы Мэрфи

Моя вариация законов Мэрфи для системных администраротов :)
1) Любой сервис имеющий значение будет снят с поддержки или как-нибудь откажет, что раньше - только вопрос времени.
- Следствие: если сервис важен, готовиться к починке надо заранее, хотя бы морально. Если нет, то надо готовить основания, чтобы можно было его отключить навсегда без последствий в любое время.
2) Чем критичнее сервис, тем чаще он будет отказывать.
- Следствие: Важные сервисы из-за модернизаций и устранения отказов обыкновенно полны костылей и хреново документированы. Смена админа, который за это отвечает чревата многократным усилением такого эффекта.
3) Высокое начальство получив доступ к системам мониторинга выхватывает оттуда информацию, которую можно использовать против сотрудников, не важно насколько это сильно имеет отношение к работе сервисов, а зачастую носящую вообще справочный характер. Вывод сделаете сами =)
4) На коллектив админов обязательно найдется коллега, который будет использовать классы, базы, сложные типы данных и экзотические языки программирования для вывода "hellow world!", потому что он так умеет. Оправдано это или нет не важно. Повезет если такой всего один. Если он отвечает за важные сервисы, см. п2 =(
- Следствие: будьте проще! К простому скрипту и костыли писать приятнее и менее опытным коллегам передать не сложно. И документировать легче.
5) Если ничего не делать, то работа сервисов развивается от хреновой к никакой.
- Следствие 1: Займись профилактикой, мониторингом и модернизацией в спокойной обстановке, а не когда все помрет!
- Следствие 2: Если профилактика приводит к еще большим проблемам или см. п. 2, НЕ ТРОГАЙ ПОКА РАБОТАЕТ!
- Следствие 3: Опытный админ всегда сделает оптимальный выбор между предыдущими пунктами, чем облегчит себе жизнь. А Высокое начальство будет видеть что он плюет в потолок.
6) Не бывает такого количества резервных копий, которое по тем или иным причинам не возможно просрать.
- Следствие: число и длительность бэкапов подбирается исходя из бюджета и времени, необходимого чтобы по-тихому уволиться.
7) Если ты подготовил raid массивы, бэкапы, холодный резерв оборудования и отказоустойчивый кластер, то из строя выйдет аплинк до оператора.
- Следствие: если аплинка 2, иди налаживать дружеские отношения с местным электриком (ну ты понял)
8) Если 80% рабочего времени уделять профилактике сбоев, оптимизации и документированию, то получится избежать всего около 20% возникающих проблем.
- Парадокс пункта 8: Если этого не делать, то 80% будет уходить на исправление косяков и получение по репе , а так же усилятся эффекты из пункта 2, 6 и 7, (особенно 2).
- Дополнение: пункт 8 лучше всего выполняется на большом отрезке времени. Все негативные эффекты и сопутствующие неприятности очень легко получить в наследство от админа, который занимался этим до тебя!
9) Инструкции для коллег и клиентов надо составлять так, чтобы они не допускали двойного толкования или неопределенности. Если есть 2 способа, и один приведет к проблемам - рано или поздно кто-то так и сделает.
- Примечание: тут по аналогии с компьютерной программой, только компиллятор хоть в большинстве случаев тебя поправит или уточнит.
10) При переносе сервисов, если ты абсолютно все учел, предполагаемое время работ надо умножать на 2-4, в зависимости от количества старых костылей и особенностей, которые всплывут в процессе работ.
11) Диски стараются выходить из строя там, где не применяются массивы в первую очередь. Питание стараются отключать во время важных работ. - Следствие: используй Силу, raid, ups и см. п7.


Буду дополнять :) И клевые байки от коллег по цеху .

Комментарии пользователей: