- PVSM.RU - https://www.pvsm.ru -
Я хотел бы обратить внимание коллег сисадминов, а так же тех, кто принимает их на работу, на два диаметрально противоположных подхода к системному администрированию. Мне кажется, понимание разницы между этими подходами может значительно уменьшить взаимное разочарование обеих сторон.
Вроде бы ничего нового, но за те почти 15 лет, что я связан с этой темой, я столько раз был свидетелем проблем, недоразумений и даже конфликтов, связанных с непониманием или нежеланием понимать разницу между этими двумя подходами, что похоже стоит лишний раз поднять тему. Если вы сисадмин и на работе вы не в своей тарелке или если вы руководитель, берущий на работу сисадмина — возможно эта статья как раз для вас.
Я буду намеренно немного утрировать, дабы сделать разницу несколько более наглядной.
Под Black Box администрированием (аналогия с чёрным непрозрачным наглухо закрытым ящиком, с кнопочками и лампочками) я понимаю ситуацию, когда есть некая система, есть инструкции по её эксплуатации, какой-то набор трюков, вопросов и ответов в гугле. Но информации как устроена система нет, мы не знаем (или не хотим знать) что у неё внутри, как она работает, что там внутри с чем и каким образом взаимодействует. Да это и не важно: если она эксплуатируется в штатных условиях мы просто знаем как ей пользоваться и чего ожидать. Заранее описан набор команд/действий, приводящих к нужным нам результатам и нам не важно как система это делает, мы просто «заказываем» и получаем результат. Или, если образно, заранее описано (или найдено методом тыка, то есть опытным путём), какую кнопку надо нажать, чтоб загорелась нужная комбинация лампочек.
Соответственно, администрирование в этом случае сводится, во первых, к поддержке штатных условий эксплуатации, при которых система ведёт себя так как оговорено, и, во вторых, к «нажатию нужных кнопочек» по запросам клиентов / пользователей. Делается это строго согласно известному знанию о том какая кнопочка какую лампочку зажигает, вариации не только не приветствуются, но даже противопоказаны, ибо другой путь может дать неожиданные побочные эффекты, вывести систему из штатного режима в состояние, которое в документации не описано, и что тогда делать, чтобы исправить ситуацию — неизвестно.
Если же что-то пошло не так и система перестала работать как должна, первое что делается — поиск что же не так с условиями эксплуатации, что отличается от того как было когда работало и как вернуть обратно, как “погасить все лампочки” и вернуть систему в исходное штатное состояние. Если это не помогает — гуглим «секретные комбинации кнопок» от знатоков и пробуем их все подряд по убыванию похожести описанной ситуации, пока заветная лампочка не зажжётся или система не вернётся в известное нам состояние. Если и это не помогает – тупик. Или откат к бекапам, или обращение в поддержку (если таковая у системы есть) или замена (переустановка) системы.
Стоит заметить, что существует некое количество систем, для которых такой подход – единственно возможный. Например, в случаях, когда устройство системы является коммерческой тайной её производителя и возможности изучения её устройства сильно ограничены договорными обязательствами и внутренними правилами компании. Или в случае огромных сложных систем со сложными внутренними взаимосвязями, поддержкой разных компонентов которой занимаются разные департаменты, не имеющие доступа к информации и не имеющие права что либо делать за пределами своей зоны ответственности. Кроме того, бывает масса случаев, когда такой подход просто более целесообразен. Например Винду часто проще переустановить, чем разбираться что же в её недрах поломалось.
Соответственно White Box — это когда ящик прозрачный. Мы имеем возможность посмотреть (а так же понять) как система устроена. При таком раскладе инструкция вторична, она позволяет понять как предполагается использовать систему и как она устроена, но не ограничивает нас этим. Есть понимание как устроена система и, как следствие, как она поведёт себя в разных условиях, в том числе и в не описанных в документации.
После того, как затрачено некое время на изучение устройтва системы, появляется понимание, почему нужно нажимать на кнопки именно в этой последовательности и почему систему надо эксплуатировать именно в таких условиях. Одни и те же действия можно делать разными способами, если это приведёт к нужному результату, ведь мы заранее можем предсказать возможные побочные эффекты, а следовательно можем выбрать наиболее эффективный способ именно для текущей задачи. Если что-то пошло не так — мы можем посмотреть что именно и как именно поломалось, какую шестерёнку подклинило. Можем осознанно вернуть систему в исходное состояние или изменить тот и только тот фактор, который мешает системе нормально работать. То есть двигаться от внутреннего состояния и потребностей системы, а не от доступной документации/опыта.
При таком раскладе, возможности решения проблем многократно возрастают, «тупик» достигается гораздо дольше и реже, система может эксплуатироваться более полно и гибко, более эффективно. Но, этот подход требует освоить, переварить и удерживать в голове на порядок большее количество информации, что гораздо дольше и сложнее.
Такой подход тоже бывает единственно доступным. Например, когда система – внутренняя разработка компании, постоянно находящаяся в развитии, меняющаяся, дополняющаяся. Следовательно никто до конца не знает что от неё ожидать, а документация зачастую отсутствует. В таком случае регулярно будут появляться ситуации, которые просто невозможно решить в разумные сроки не понимая как система устроена и не умея «копаться в её шестерёнках».
Из моего личного опыта, могу сказать, что большинство сисадминов чувствуют себя комфортнее (а так же более эффективны) в рамках какого-то одного из этих двух подходов, и, соответственно, не в своей тарелке, когда есть нужда большую часть времени работать в рамках другого подхода.
Рассмотрим оба варианта на реальном (слегка упрощённом, дабы не тратить время на несущественные детали) примере из жизни.
Некий сайт работает на 2-х 8-ядерных машинах с 8Гб памяти. Apache2+PHP+MySQL+memcache. В пиковые часы периодически система начинала жутко тормозить а сам сайт отвечать с задержками в 10-30 секунд или вообще не отвечать.
На обоих серверах команда top показала, что свободной памяти почти нет, load average в районе 20, активно используется swap и система не вылезает из iowait-а. Перезапуск apache вернул всё в нормальное состояние. После чего в cron вставили рестарт apache раз в час и про проблему благополучно забыли ещё на полгода…
Что конкретно происходило и почему это происходило — осталость неизвестным, актуальная проблема была «сайт тормозит и не открывается», проблема решена, сайт больше не тормозит. Диагностика — 3 минуты, решение — ещё 5 минут. То есть за неполные 10 минут проблема устранена, не зная почти ничего о том почему проблемма появилась. Нет никакой уверенности что это поможет на долго и что это вообше решение, но (!) 10 минут и по факту сайт снова работает без проблем ещё почти полгода.
Через полгода проблема стала появляться снова не смотря на ежечасный рестарт апача. Стали уменьшать интревал рестарта, стали появляться жалобы, что соединение с сайтом иногда просто обрывается, страница получается недозагруженной. То есть само решение проблемы начало создавать новые проблемы.
Опущу детали процесса, в результате которого система была изучена чуть ли не под микроскопом, остановлюсь сразу на выводах. Выяснилось:
Решение было таким (с учётом специфики проекта, которая тут не описана):
В итоге, в час пик работает одновременно не более 25-30 лёгеньких апачей, 5-10 больее тяжёлых отдельных php через mod_fpm, немного шевелится node.js занимая не более 2-5 процессов апача одновременно на своих микро запросиках. Nginx очередь, если вдруг образовывается, держит легко, не напрягаясь, при этом процессор почти не потребляет, ибо сам ничего не делает, только проксирует и, благодаря своей архитектуре, с поддержанием нескольких сотен одновременных сессий сложностей не имеет ну совсем никаких. Кроме того, nginx буферизует ответы апача и уже сам не спеша отаёт их клиенту, что позволяет apache освободиться от запроса быстрее.
Как следствие, средий load average на серверах в “час пик” гуляет в районе 0.2-0.5. Потребление памяти – около 2-3GB на все процессы. Остальная память – cache. Swap не используется. Время отклика теперь не меняется в час пик и стало примерно равным тому же что и в тихое время (когда на сайте всего 2-3 клиента).
Количество клиентов которое сайт может обслужить не имея проблем с нагрузкой возросло примерно в 10 раз (дальше уже начинаются сложности с базой данных).
То есть проблема снова решена, но на этот раз с огромным запасом и чётко понимая на что рассчитывать и как долго это будет работать без проблем. Всё обоснованно, продуманно, взвешено. Время решения — 2 недели...
Рискуя получить звание “капитана очевидности”, перейду к следствиям такого “разделения”:
При выборе работника или работы вспомните эти несколько пунктов и возможно вы сэкономите время, деньги и нервы. Вот пожалуй и всё по этой теме. Спасибо тем кто дочитал. :)
Автор: Yozhiks
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/sistemnoe-administrirovanie/15719
Нажмите здесь для печати.