Black Box vs White Box в системном администрировании

    image

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

    Вроде бы ничего нового, но за те почти 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 недели...

    Итоги

    Рискуя получить звание “капитана очевидности”, перейду к следствиям такого “разделения”:

    1. Стоит прикинуть какого типа системы нужно обслуживать на вашей фирме, прежде чем подбирать сисадмина. Black-Box-guru в случае сложных самодельных постоянно меняющихся систем врядли будет так же полезен как white-box-guru, и вряд ли будет доволен своей работой. White-box-guru в случае стабильных, отлаженных систем, в которые нежелательно “залезать внутрь” вообще не будет находить себе места и скорей всего будет работать только формально, всё свободное время занимаясь какими-то своими, личными проектами и экспериментами. Ну или будет постоянно пытаться “переделать тут всё правильно, а не как оно сейчас”.
    2. Сисадмину стоит “понять себя”, какой подход ближе к сердцу, и выбирать себе работу с учётом этого понимания.
    3. Black-box-guru решает проблемы очень быстро, так же быстро способен взять на обслуживание новые хорошо задокументированные и широко используемые системы. Результаты стабильны и предсказуемы. Проблемы предпочитает решать однотипно и предсказуемо (и часто это огромный плюс, особенно при работе в команде), но не всегда оптимально.
    4. White-box-guru тратит значительное время на изучение системы, но зато потом выдаёт гораздо более эффективные решения. Способен решать более сложные задачи и те для которых настало состояние “тупика” у black-box-guru, но не так быстро и не так много. При этом практически бесполезен при быстром “тушении пожаров”, потому как вместо того чтобы просто быстро перезапустить apache будет рассматривать что происходит “по горячим следам”, изучать состояние системы в её нездоровом состоянии “пока видно”.
    5. В крупной фирме не обойтись без команды с админами обоих типов: пока одни быстро “тушат пожар”, то есть делают чтобы система заработала хоть как-то, другие спокойно разбираются в корнях проблем и делают так, чтобы они уже никогда не повторились. И этих вторых не надо заставлять делать то что хорошо делают первые, и наоборот — ничего хорошего из этого не выйдет.
    6. Самые ценные, но и самые редкие кадры – это те кто могут успешно работать по обоим подходам, но и им больше по душе (комфортнее) всё же какой-то один подход.


    При выборе работника или работы вспомните эти несколько пунктов и возможно вы сэкономите время, деньги и нервы. Вот пожалуй и всё по этой теме. Спасибо тем кто дочитал. :)
    Share post
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 18

      +11
      Как по мне, Black Box и White Box это скорее категории методов решения задач, а не категории админов. Если у админа хватает знаний о системе, чтобы докопаться до сути проблемы, он применит white-box метод для ее решения (иными словами подправит что-то внутри системы), если знаний не хватает — в ход пойдут black box методы (влияние на систему извне).

      Представьте, что Вашу проблему с Apache2+PHP+MySQL+memcache сайтом пришел решать человек с улицы. Он осмотрит сервер (вентилятор гудит, лампочки горят, сетевой провод на месте) и решит перезагрузить его. Проблема решена. Сайт снова на ходу.

      Но приходит админ. Для него перезагрузка сервера — типичный black box подход. Можно ведь зайти в систему и посмотреть, что там творится. Ага, память жрет апач. Будем каждый час перезагружать его.

      Но приходит более опытный админ. Для него предыдущие два подхода к решению проблемы — black box. Он выбирает более подходящий софт, оптимизирует

      Но приходит гуру-админ и говорит: «Что это за зоопарк у вас: и nginx, и apache, и node.js… tomcat-a не хватает для полного счастья». Он переписывает web-приложение на С++.

      Но приходит супер-мега-гуру-админ и говорит: «Интеловская архитектура для этой задачи подходит плохо». Он паяет свой процессор и пишет web-приложение (которое по совместительству является и ОС) на ассемблере.

      Но приходит человек в белом плаще и говорит: «Ну-ну-ну, развели тут АйТи. Давайте, сворачивайтесь. Информацию пользователям эффективнее подавать прямо в мозг». Он жмет кнопку какого-то своего прибора и этим решает проблему.
        +2
        На этапе «админ переписывает на Си» можно сворачиваться. Разработка софта (если это не карманные утилиты для собственного упрощения бытия) требует не «пришёл и написал», а «написал и сопровожаю». А это совсем не админская задача, и процессы разработки софта совершенно не совместимы с «гуру, который пишет». Точнее, совместимы, но только при условии, что есть инфраструктура. Если инфраструктуры нет, то это не написание софта, это построение дымоходов (т.е. проектов без внятной документации и внутренней логики, в которых разбирался хорошо ушедший 2 года назад сотрудник, а умел поддерживать тот админ, что сейчас оформляет увольнение в бухгалтерии).

        Я с подобным работал — и могу сказать, что это отвратительно. Мне потребовалось три года совпровождения такого дымохода, чтобы выяснить, что NETBIOS имя MSSQL захардкожено в logrotate на secondary DNS-сервере в Московском филиале, и этот скрипт Очень Важен, чтобы московский филиал мог обновлять свои грёбанные цены на нашем сайте в асинхронном режиме (с лежащим VPN'ом).
          0
          Шорошо, давайте переформулируем немного иначе. Есть 2 категории решения задач. И большинство админов (не все) тяготеют к использованию приемущественно одной из них и будучи поставлены в условия необходимости использовать приемущественно другую категорию — становятся менее эффективны и менее довольны собой и своей работой.
            0
            И ещё момент. Как правило, рано или поздно знаний не хватает. И ключевой момент, что человек сделает в этот момент первым: будет дополучать недостающие знания и доразбираться (если это конечно возможно) или будет искать готовое заклинание на просторах гугля не вникая в суть происходящего. Я встречал и тех и других.
            +4
            В реальности же ситуация выглядит так:

            «А сломалось»
            (white mode) я знаю, что там не так с А, ща поправлю.
            «А.b как-то не так себя ведёт»
            (still white mode) Я знаю эту компоненту, ща поправлю.
            «A.b.3 пишет ахинею, из-за этогоне работает A.b, из-за этого не работает А»
            (not so white) Ща посмотрю, но я 3 глубоко не копал.
            «A.b.3.IV читает из foobar2, спотыкается на выводе, из-за рейса с baz4 barbar5 не успевает обновить поля и A.b.3.V не получает нужных данных»
            (wild search) Я в жизни не видел сырцов barbar5 и не понимаю в каких терминах оно описывается. Что такое E820 reserved page numbers? Откуда ядро берёт указатель на start_info при запуске? Почему last_pnf показывается дважды?
            (...skip...)
            (deep black box) С помощью какой-то матери удалось найти комбинацию ядра, модуля и версии libc, в которой бага проявляется раз в три часа, я там запустил шелловый скрипт, который интерфейс передёргивает, будем разбираться потом, пока что вроде работает.

              0
              ИМХО то что вы сейчас описали есть ка раз разные уровни Black Box'a. Точнее BlackBox-матрёшка. Ни на одном из описанных вами этапов нет стадии выяснения как система реально устроена, как работает и что может приводит к проблеме. Впрочем, конечно же это и не всегда возможно. Как я уже упоминал, есть масса систем, для которых White Box подход или невозможен (недоступность информации, лимиты по времени, сложность системы) или нецелесообразен.
              +1
              Не смог себя определить в какую-либо категорию.
              Всё сильно зависит от типа проблемы, её серьезности и доступного для её решения времени.
              Чаще всего сначала применяется быстрое «затыкание дыр» чтоб восстановить сервис, а дальше начинается изучение логов и попытка понять что же на самом деле там внутри произошло.
                +1
                White-box-guru… вместо того чтобы просто быстро перезапустить apache будет рассматривать что происходит “по горячим следам”, изучать состояние системы в её нездоровом состоянии “пока видно”.

                Забыв на минуту про Apache — есть масса случаев, когда принцип «ничего не работает — включить выключить пробовали?» не только не поможет, но и сделает все только хуже (как минимум увеличит время восстановления сервиса, если дело не в глюке, а в неправильной конфигурации — а отличить глюк от ошибки в конфиге не всегда легко).
                В случае аварии подход White-box-guru все равно более правильный: нужно потратить несколько лишних минут на сбор информации и анализ того, какой воркараунд или фикс в данной ситуации уместен. Если воркараунд сработал — продолжать анализ собранных данных, создать кейс вендору и т.д. Вендора запрашиваем, потому что на определенном уровне любая система превращается в black box (либо исходников нет, либо они есть, но изучить их нереально), и кейс вендору на самом деле является продолжением тактики «White-box-guru» — в результате будет получено решение исходя из устройства системы.
                  0
                  В терминах ITIL вы описали два разных процесса. Управление инцидентами (чтото сломалось — как можно быстрее восстановить работу любыми способами не углубляясь в детали) и Управление проблемами (детально рассматриваем инцидент ищем причины ищем способы решить вопрос дабы он больше не всплывал)
                    0
                    Да, именно так. И, по моему мнению, на этих 2 разных процесса желательны люди с по разному заточенными мозгами.
                    0
                    Ух ты, а я оказывается White-box-guru… Спасибо, не знал.
                      +1
                      Еще забыли упомянуть что Black Box и White Box подходы зачастую применяются последовательно. Например: «Аааа, все пропало, сервер тормозит, клиенты оборвали телефоны, отматерили всех операторов, сделайтечтонибудьнемедленнобля!».

                      В этом случае сначала рестартуют сервисы и перезагружают сервер (Black Box) и уже потом применяют White Box.
                        0
                        Данные походы часто учитывают и программисты. К примеру программа может позволять вручную редактировать и добавлять данные, а может просто иметь 101 диалог, которые покрывают почти все возможные сценарии действий пользователя.
                          +1
                          2 недели на то, чтобы понять проблему с Apache и php? white-box-guru такой классный, а то, что LA до 30 дошло и система свопится не заметил? Как вы тогда назовете админа который мониторит систему постоянно? green box? И почему white box не догадался еще до запуска, что надо ставить nginx перед апачем в любом случае?
                            +1
                            У меня почему-то сложилось впечатление что Вы невнимательно прочитали.
                            0
                            В Вашем примере Black Box подход напоминает «вытирание с пола воды при пробитой трубе» а White Box подход — «починку той самой трубы».
                            И разница тут не в двух подходах, а в требованиях к системе, с которой случается беда. В данном случае, естественно, было принято решение быстрее организовать доступ к сайту. В идеале, после того, как сисадмины «вытерли воду» им надо было запланировать техобслуживание на выяснение причин, а не ждать следующих проблем (лирическое отступление).

                            Плюс, такое четкое разграничение не слишком правильное. Даже некоторые White Box методы могут напоминать «сигналы лампочек» а совсем не «заклиненные шестеренки». Иногда «починить трубу» методами BlackBox может быть куда более эффективно, чем методами White Box (кто пытался починить свои часы в детстве — поймет :))

                            Сисадмину стоит “понять себя”, какой подход ближе к сердцу, и выбирать себе работу с учётом этого понимания.

                            Ну… я бы сказал «стремитесь к WhiteBox, не забывая про BlackBox»
                              0
                              В статье я писал:
                              1. «Я буду намеренно немного утрировать, дабы сделать разницу несколько более наглядной.»
                              2. «Рассмотрим оба варианта на реальном (слегка упрощённом, дабы не тратить время на несущественные но трудоёмкие детали)»

                              То есть:
                              Это всего лишь упрощённая и несколько преувеличенная илюстрация, хоть и основанная на виденной мною реальной ситуации. Хотите — предложите более удачную, с благодарностью вставлю в статью. ИМХО, оценивать действия людей из такого примера — это всё равно что вести диалог с телевизором…

                              Цель этой статьи — показать что есть разные подходы со своими плюсами и минусами, и разные люди чувствуют себя более комфортно в рамках одного из них (что я тоже многократно наблюдал). При этом часто на тех кто более склонен к другому подходу смотрят как на неадекватов.

                              Судя по вашему коментарию, вам более интересен и близок white box. Ответьте себе честно, будете ли вы довольны своей работой, если вам придётся 99% времени заниматься «вытиранием воды» а не «починкой труб»? А есть люди которые этим занимаются с удовольствием и ничего другого им не надо. В гробу они видали разбираться с этими трубами. Они лучше просто вытрут то что натекло пока кто-то другой чинит трубу.

                              Задачи бывают разные, системы бывают разные, люди нужны и те и другие. И каждый на своём месте.
                                0
                                Взгрустнулось и вспомнилось памятное www.opennet.ru/openforum/vsluhforumID3/13630.html

                                Про слакваритс-кувалдист vs «изучил инструкцию-наладил связь с техподдержкой-правильно разруливаю стрелки-умею заставить выпустить официальный патч производителя».

                            Only users with full accounts can post comments. Log in, please.