Pull to refresh

Comments 18

Как по мне, 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 года назад сотрудник, а умел поддерживать тот админ, что сейчас оформляет увольнение в бухгалтерии).

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

«А сломалось»
(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, в которой бага проявляется раз в три часа, я там запустил шелловый скрипт, который интерфейс передёргивает, будем разбираться потом, пока что вроде работает.

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

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

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

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

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

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

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

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

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

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

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

Articles