Тест Лимончелли

Обновлено 2024-02-01 6 мин. для прочтения Computer-Science

Тест Лимончелли
- 32 краеугольных принципа хорошей команды системного администрирования.

Содержание

1 Общая информация

Сайт (англ): https://www.opsreportcard.com/
Перевод (русский): https://docs.google.com/document/u/0/d/1r2-0CH-ZnCjzyl214JRu4jYr25HHNPGoRtE5QQlDe1M/pub
Основные правила организации инфраструктуры системного администрирования, сформулированные в виде тестов.
Даются вопросы с их обсуждением.

2 Подходы по работе с пользователями:

2.1 Используете ли вы систему отслеживания запросов?

Упрощает обмен информацией в команде.
- Позволяет избегать ситуаций, когда два человека одновременно работают над одним и тем же запросом.
- Даёт возможность делить работу межу людьми, передавать работу между собой, не теряя информации.
- Даёт возможность подменять администратора, который недоступен.
Делает работу команды прозрачнее.
- Пользователи видят кто работает над запросом, какой у него статус, и когда он выполнен.
Позволяет эффективнее использовать рабочее время.
- Уменьшает количество прерываний от пользователей, которые хотят сделать новый запрос или узнать статус открытого запроса.
- Позволяет задавать приоритеты в работе администратора, а не решать проблемы пользователя, который жалуется громче всех.
Позволяет обнаружить системные проблемы.
Позволяет пользователям помогать самим себе.
- Формулируя проблему, пользователь сам находит её решение и запрос так и не отправляется.
- Процесс отправки помогает пользователю продумать проблему и сформулировать её яснее.

2.2 Есть ли у вас три регламентирующие политики и знают ли о них?

Три политики, регламентирующие вашу работу с пользователями:
- Доступные пользователям способы запроса помощи.
- Определение аварийной ситуации.
- Объем обслуживания: кто, что и где.

2.2.1 Как получить помощь

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

У системного администратора должны быть возможность отказать пользователю, когда тот не соблюдает протокол. Без возможности отослать пользователя к официальной политике, администраторы будут работать либо над низкоприоритетными задачами, либо для пользователей, которые громче всех жалуются, либо каждый из них будет пользоваться своей личной политикой, тем самым выставляя всю команду непоследовательной, а в худшем случае будут нездоровым способом демонстрировать свое неудовлетворение. Точнее, нездоровым для пользователей способом.

2.2.2 Определение аварии:

Официальное определение аварийной ситуации позволяет системным администраторам расставлять приоритеты. Без этого определения, всё становится авралом, и снова сисадмины будут постоянно отвлекаться на мелочи, а их эффективность сильно понизится.

Политика — это один из способов, которым руководство коммуницирует приоритеты системным администраторам. В противном случае, сисадмины будут строить догадки о приоритетах, ошибаться, их будут несправедливо за это наказывать; менеджеры будут расстраиваться из-за “дисконнектов”, а пользователи, видя непоследовательность, будут предполагать фаворитизм, халатность и некомпетентность.

Это политика определяет ожидания пользователей. С ее помощью можно корректировать иллюзии пользователей, которые считают любой происшествие аварийной ситуацией.

Каждая организация должна иметь определение аварии или “красного сигнала”. Для газеты — это все, что блокирует печать завтрашнего номера и его погрузку в грузовики в 4 утра. “Красный сигнал” на заводе — это все, что останавливает конвейер. Авария для отдела платежей — все, что делает невозможным проведение платежей. Команды, работающие в сфере образования, знают, что перенести занятие совсем не просто, потому аварийной ситуацией является все, что мешает надлежащему проведению лекции (возможно, только если технологический центр был заблаговременно предупрежден). В университетах “красный сигнал” определен, как любая преграда для своевременной подачи заявок на получение грантов.

“Желтый сигнал” — это все, что приведет к “красному”, если останется без внимания. Например, оплаты проводятся, но не работает подсистема оценки доступных запасов. В таком случае очень рискованно брать новых клиентов. Последняя оценка говорила о запасах, достаточных на 2 недели. Риск остановки производства растет с каждым днем, пока “желтый сигнал” не будет исправлен.

Все остальное — это рутина. Изобретательные компании разделяют рутинные задачи по приоритетам: высокий, средний, низкий; создание нового сервиса, поддержка существующих, и т.д. Если у вас ничего такого нету, начните с определения, что представляет собой авария.

2.2.3 Что поддерживается:

Официальное определение поддерживаемых сервисов позволяет администраторам говорить “нет”. Должно быть определено когда, где, кто и что поддерживается. Работает ли команда после 6 вечера? На выходных? Ходят ли администраторы по вызову к рабочему месту пользователя? Домой к пользователю? Поддерживаете ли вы кого-либо, кроме сотрудников компании? Какое программное и аппаратное обеспечение поддерживается? Есть ли у поддерживаемого обеспечения жизненный цикл, или вы обречены его поддерживать вечно? Новые технологии включаются в поддержку автоматически или после официального утверждения?

Не имея возможности сказать “нет”, администраторы будут поддерживать всё. Отзывчивый и старательный сисадмин потратит кучу времени, пытаясь заставить работать неподдерживаемую видеокарту, при том, что дешевле будет подарить этому пользователю поддерживаемую карту за счет бюджета СА. Пропавший без вести системный администратор вдруг найдется, после дня, проведенного у пользователя дома, где он ремонтировал Интернет-подключение. Или наоборот, ворчливый сисадмин будет говорить людям, что они это не поддерживают, просто потому, что он занят.

2.3 Ведёт ли команда ежемесячные метрики?

3 Современные подходы в работе:

3.1 Есть ли у вас вики с описанием политик и процедур?

3.2 Есть ли у вас место, где хранятся пароли?

Хранится ли ваш код в системе управления версиями?
Использует ли ваша команда систему отслеживания ошибок для своего кода?
В ваших задачах обеспечение стабильности приоритетнее новых возможностей?
Пишет ли ваша команда проектную документацию?
Выполняете ли вы анализ причин происшествия?

4 Операционные подходы:

*11. Есть ли у вас документация (OpsDoc) на все ваши сервисы?

*12. Имеет ли каждый сервис необходимый мониторинг?

Есть ли у вас график дежурств?
Используете ли вы отдельные системы для разработки, тестирования и производства?
Используется ли “канареечный процесс” при внесении изменений на большое количество машин?

5 Подходы по автоматизации:

Используете ли вы инструменты управления конфигурацией, такие как cfengine/puppet/chef?
Выполняются ли автоматизированные задачи под ролевыми учетными записями?
Ваши автоматизированные задачи шлют почту только когда есть полезная информация?

6 Подходы по управлению парком машин

*19. Есть ли у вас база данных всех машин?

Автоматизирован ли у вас процесс установки ОС?

*21. Можете ли вы автоматически обновлять ПО для всего парка машин?

Есть ли у вас политика обновления компьютеров?

7 Подходы серии Мы согласны, что техника ломается

*23. Будут ли работать ваши сервера, если на них откажет один из дисков?

Используется ли схема N+1 в ядре вашей сети?

*25. Автоматизировано ли ваша процедура резервного копирования?

*26. Проверяете ли вы периодически свой план аварийного восстановления?

Есть ли в вашем ЦОД системы удаленного управления питанием и доступа к консолям?

8 Подходы к безопасности:

*28. Ваши сервера/ноутбуки/компьютеры защищены автоматически обновляемым антивирусным ПО?

*29. Есть ли у вас политика безопасности в письменном виде?

Проводите ли вы регулярный аудит безопасности?
Можете ли вы отключить учетную запись пользователя во всех системах за 1 час?
Можете ли вы сменить все привилегированные (root) пароли за 1 час?