Я хотел бы обратить внимание коллег сисадминов, а так же тех, кто принимает их на работу, на два диаметрально противоположных подхода к системному администрированию. Мне кажется, понимание разницы между этими подходами может значительно уменьшить взаимное разочарование обеих сторон.
Вроде бы ничего нового, но за те почти 15 лет, что я связан с этой темой, я столько раз был свидетелем проблем, недоразумений и даже конфликтов, связанных с непониманием или нежеланием понимать разницу между этими двумя подходами, что похоже стоит лишний раз поднять тему. Если вы сисадмин и на работе вы не в своей тарелке или если вы руководитель, берущий на работу сисадмина — возможно эта статья как раз для вас.
Я буду намеренно немного утрировать, дабы сделать разницу несколько более наглядной.
Black Box администрирование
Под Black Box администрированием (аналогия с чёрным непрозрачным наглухо закрытым ящиком, с кнопочками и лампочками) я понимаю ситуацию, когда есть некая система, есть инструкции по её эксплуатации, какой-то набор трюков, вопросов и ответов в гугле. Но информации как устроена система нет, мы не знаем (или не хотим знать) что у неё внутри, как она работает, что там внутри с чем и каким образом взаимодействует. Да это и не важно: если она эксплуатируется в штатных условиях мы просто знаем как ей пользоваться и чего ожидать. Заранее описан набор команд/действий, приводящих к нужным нам результатам и нам не важно как система это делает, мы просто «заказываем» и получаем результат. Или, если образно, заранее описано (или найдено методом тыка, то есть опытным путём), какую кнопку надо нажать, чтоб загорелась нужная комбинация лампочек.
Соответственно, администрирование в этом случае сводится, во первых, к поддержке штатных условий эксплуатации, при которых система ведёт себя так как оговорено, и, во вторых, к «нажатию нужных кнопочек» по запросам клиентов / пользователей. Делается это строго согласно известному знанию о том какая кнопочка какую лампочку зажигает, вариации не только не приветствуются, но даже противопоказаны, ибо другой путь может дать неожиданные побочные эффекты, вывести систему из штатного режима в состояние, которое в документации не описано, и что тогда делать, чтобы исправить ситуацию — неизвестно.
Если же что-то пошло не так и система перестала работать как должна, первое что делается — поиск что же не так с условиями эксплуатации, что отличается от того как было когда работало и как вернуть обратно, как “погасить все лампочки” и вернуть систему в исходное штатное состояние. Если это не помогает — гуглим «секретные комбинации кнопок» от знатоков и пробуем их все подряд по убыванию похожести описанной ситуации, пока заветная лампочка не зажжётся или система не вернётся в известное нам состояние. Если и это не помогает – тупик. Или откат к бекапам, или обращение в поддержку (если таковая у системы есть) или замена (переустановка) системы.
Стоит заметить, что существует некое количество систем, для которых такой подход – единственно возможный. Например, в случаях, когда устройство системы является коммерческой тайной её производителя и возможности изучения её устройства сильно ограничены договорными обязательствами и внутренними правилами компании. Или в случае огромных сложных систем со сложными внутренними взаимосвязями, поддержкой разных компонентов которой занимаются разные департаменты, не имеющие доступа к информации и не имеющие права что либо делать за пределами своей зоны ответственности. Кроме того, бывает масса случаев, когда такой подход просто более целесообразен. Например Винду часто проще переустановить, чем разбираться что же в её недрах поломалось.
White Box
Соответственно White Box — это когда ящик прозрачный. Мы имеем возможность посмотреть (а так же понять) как система устроена. При таком раскладе инструкция вторична, она позволяет понять как предполагается использовать систему и как она устроена, но не ограничивает нас этим. Есть понимание как устроена система и, как следствие, как она поведёт себя в разных условиях, в том числе и в не описанных в документации.
После того, как затрачено некое время на изучение устройтва системы, появляется понимание, почему нужно нажимать на кнопки именно в этой последовательности и почему систему надо эксплуатировать именно в таких условиях. Одни и те же действия можно делать разными способами, если это приведёт к нужному результату, ведь мы заранее можем предсказать возможные побочные эффекты, а следовательно можем выбрать наиболее эффективный способ именно для текущей задачи. Если что-то пошло не так — мы можем посмотреть что именно и как именно поломалось, какую шестерёнку подклинило. Можем осознанно вернуть систему в исходное состояние или изменить тот и только тот фактор, который мешает системе нормально работать. То есть двигаться от внутреннего состояния и потребностей системы, а не от доступной документации/опыта.
При таком раскладе, возможности решения проблем многократно возрастают, «тупик» достигается гораздо дольше и реже, система может эксплуатироваться более полно и гибко, более эффективно. Но, этот подход требует освоить, переварить и удерживать в голове на порядок большее количество информации, что гораздо дольше и сложнее.
Такой подход тоже бывает единственно доступным. Например, когда система – внутренняя разработка компании, постоянно находящаяся в развитии, меняющаяся, дополняющаяся. Следовательно никто до конца не знает что от неё ожидать, а документация зачастую отсутствует. В таком случае регулярно будут появляться ситуации, которые просто невозможно решить в разумные сроки не понимая как система устроена и не умея «копаться в её шестерёнках».
Суть проблемы
Из моего личного опыта, могу сказать, что большинство сисадминов чувствуют себя комфортнее (а так же более эффективны) в рамках какого-то одного из этих двух подходов, и, соответственно, не в своей тарелке, когда есть нужда большую часть времени работать в рамках другого подхода.
Рассмотрим оба варианта на реальном (слегка упрощённом, дабы не тратить время на несущественные детали) примере из жизни.
Некий сайт работает на 2-х 8-ядерных машинах с 8Гб памяти. Apache2+PHP+MySQL+memcache. В пиковые часы периодически система начинала жутко тормозить а сам сайт отвечать с задержками в 10-30 секунд или вообще не отвечать.
Для начала проблему рассматривали по Black Box подходу.
На обоих серверах команда top показала, что свободной памяти почти нет, load average в районе 20, активно используется swap и система не вылезает из iowait-а. Перезапуск apache вернул всё в нормальное состояние. После чего в cron вставили рестарт apache раз в час и про проблему благополучно забыли ещё на полгода…
Что конкретно происходило и почему это происходило — осталость неизвестным, актуальная проблема была «сайт тормозит и не открывается», проблема решена, сайт больше не тормозит. Диагностика — 3 минуты, решение — ещё 5 минут. То есть за неполные 10 минут проблема устранена, не зная почти ничего о том почему проблемма появилась. Нет никакой уверенности что это поможет на долго и что это вообше решение, но (!) 10 минут и по факту сайт снова работает без проблем ещё почти полгода.
Через полгода проблема стала появляться снова не смотря на ежечасный рестарт апача. Стали уменьшать интревал рестарта, стали появляться жалобы, что соединение с сайтом иногда просто обрывается, страница получается недозагруженной. То есть само решение проблемы начало создавать новые проблемы.
Далее, эту же систему стали рассматривать подробнее. Как White Box.
Опущу детали процесса, в результате которого система была изучена чуть ли не под микроскопом, остановлюсь сразу на выводах. Выяснилось:
- Разные запросы к серверу отнимают сильно разное количество памяти, есть небольшое количество запросов кушающих аж до 200 мегабайт, но основная масса потребляет не более 5-10. При этом php память освобождает, а вот apache в рамках одного child'a память уже не освобождает, держит при себе, чтоб если понадобится — уже была. В результате получаем, что рано или поздно через каждый child пройдёт хоть один тяжёлый запрос, в результате чего апач «припасёт» памяти на будущее куда больше, чем понадобится большинству последующих запросов.
- Количество «деток» апача стоит доволно большое 250 штук, что при плавном их «потолстении» до 200MБ плавно, но неизбежно приводит к потреблению памяти куда большему, чем имеется в системе. Система начинает свапиться, всё начинает работать медленнее, запросы обрабатываются медленнее, а поступают так же, что приводит к большему количеству одновременных запросов, что приводит к тому что все 250 деток апача активно задействованы и имеют очередь запросов и все вместе активно «полнеют» и свапятся.
- Кроме того несколько ускоряло этот растущий снежный ком некоторое количество long-polling запросов постоянно висящих на фоне и, как следствие, держащих занятыми дополнительные child'ы апача, что не позволяло лишним процессам апача завершаться из-за «слишком много неиспользуемых child'ов».
Решение было таким (с учётом специфики проекта, которая тут не описана):
- на входе поставили nginx, он от количества запросов и очереди не «толстеет».
- Nginx по url match пробрасывал тяжёлые запросы на отдельный инстанс apache с mod-fpm, тем самым исключив проблему «зажатой впрок» памяти в корне, разрешив максимум 25 параллельных процессов и всего 5 запасных процессов (max spare childs).
- «лёгкие» запросы пошли на обычный apache, который перестал «толстеть» но на всякий случай всё равно поставили максимум 1000 запросов на child'a, чтобы, ежели вдруг чего, пямять всё-таки периодически освобождалась.
- Long polling, при поддержке программистов, вообще направили на маленький node.js серверочек который для каждого клиента раз в секунду проксирует запросик к апачу, предварительно глянув есть ли флажок о «свежих данных» в memcache и «пропуская кон» если ничего свежего не появилось. Эти запросы очень лёгенькие, для апача они больше не long-polling и происходят только когда реально есть новые данные — эти запросики пролетают за микросекунды и даже не заметны, практически не занимают apache-child'ов.
- Кроме того (спасибо pinba) ещё и слегка поправили сами скрипты, некоторые из них после этого стали кушать меньше а работать быстрее.
В итоге, в час пик работает одновременно не более 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 недели...
Итоги
Рискуя получить звание “капитана очевидности”, перейду к следствиям такого “разделения”:
- Стоит прикинуть какого типа системы нужно обслуживать на вашей фирме, прежде чем подбирать сисадмина. Black-Box-guru в случае сложных самодельных постоянно меняющихся систем врядли будет так же полезен как white-box-guru, и врядли будет доволен своей работой. White-box-guru в случае стабильных, отлаженных систем, в которые нежелательно “залезать внутрь” вообще не будет находить себе места и скорей всего будет работать только формально, всё свободное время занимаясь какими-то своими, личными проектами и экспериментами. Ну или будет постоянно пытаться “переделать тут всё правильно, а не как оно сейчас”.
- Сисадмину стоит “понять себя”, какой подход ближе к сердцу, и выбирать себе работу с учётом этого понимания.
- Black-box-guru решает проблеммы очень быстро, так же быстро способен взять на обслуживание новые хорошо задокументированные и широко используемые системы. Результаты стабильны и предсказуемы. Проблемы предпочитает решать однотипно и предсказуемо (и часто это огромный плюс, особенно при работе в команде), но не всегда оптимально.
- White-box-guru тратит значительное время на изучение системы, но зато потом выдаёт гораздо более эффективные решения. Способен решать более сложные задачи и те для которых настало состояние “тупика” у black-box-guru, но не так быстро и не так много. При этом практически бесполезен при быстром “тушении пожаров”, потому как вместо того чтобы просто быстро перезапустить apache будет рассматривать что происходит “по горячим следам”, изучать состояние системы в её нездоровом состоянии “пока видно”.
- В крупной фирме не обойтись без команды с админами обоих типов: пока одни быстро “тушат пожар”, то есть делают чтобы система заработала хоть как-то, другие спокойно разбираются в корнях проблем и делают так, чтобы они уже никогда не повторились. И этих вторых не надо заставлять делать то что хорошо делают первые, и наоборот — ничего хорошего из этого не выйдет.
- Самые ценные, но и самые редкие кадры – это те кто могут успешно работать по обоим подходам, но и им больше по душе (комфортнее) всё же какой-то один подход.
При выборе работника или работы вспомните эти несколько пунктов и возможно вы сэкономите время, деньги и нервы. Вот пожалуй и всё по этой теме. Спасибо тем кто дочитал. :)
Автор: Yozhiks
