Black box что это

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

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

Вроде бы ничего нового, но за те почти 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) ещё и слегка поправили сами скрипты, некоторые из них после этого стали кушать меньше а работать быстрее.

Как следствие, средний 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. Самые ценные, но и самые редкие кадры – это те кто могут успешно работать по обоим подходам, но и им больше по душе (комфортнее) всё же какой-то один подход.

При выборе работника или работы вспомните эти несколько пунктов и возможно вы сэкономите время, деньги и нервы. Вот пожалуй и всё по этой теме. Спасибо тем кто дочитал. 🙂

Работает и на территории России: в ГУР рассказали о результатах работы загадочной «Black Box»

Только за последний месяц загадочной «Black Box», на которую собирали волонтеры, нанесла оккупантам ущерб на сотни миллионов долларов. Проект работает как на временно оккупированных территориях, так и на территории России.

Начальник ГУР МО Украины Кирилл Буданов рассказал о работе Black Box. Он отметил, что это лишь часть информации, которую можно обнародовать.

Что такое «Black Box»

Результаты работы «Black Box»

В разведке сообщили, что за последний месяц он нанес оккупантам ущерб более чем на 700 миллионов долларов. В ГУР отметили, что результаты работы Black Box можно увидеть на многих объектах окупантов, даже на территории страны-агрессорки.

Более 700 миллионов долларов – наш очередной вклад в снижение наступательного потенциала армии врага, деморализации боевого духа и принятие им своего поражения в этой войне,
– сказал Буданов.

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

black box

Up to now, the brain was a black box for us. — До сих пор мозг оставался для нас загадкой.

Англо-русский экономический словарь .

Полезное

Смотреть что такое «black box» в других словарях:

Black box — is a technical term for a device or system or object when it is viewed primarily in terms of its input and output characteristics. Almost anything might occasionally be referred to as a black box: a transistor, an algorithm, humans, the Internet … Wikipedia

Black-Box — engl. [blæk bɔks], (dt. schwarzer Kasten) steht für: allgemein ein geschlossenes System unter Vernachlässigung des inneren Aufbaus, siehe Black Box (Systemtheorie) – dort auch zur Wortherkunft einen dunklen und schallisolierten Raum, siehe Camera … Deutsch Wikipedia

Black Box — Black|box, die; , es, Black Box, die; , es [ blɛkbɔks , bɔks; engl. black box, eigtl. = schwarzer Kasten]: 1. (Kybernetik) Teil eines kybernetischen Systems, dessen Aufbau u. innerer Ablauf erst aus den Reaktionen auf eingegebene Signale… … Universal-Lexikon

Black box — Cette page d’homonymie répertorie les différents sujets et articles partageant un même nom. Black Box, boîte noire en anglais, peut faire référence à : Black Box Corporation, une entreprise internationale spécialisée dans les services et… … Wikipédia en Français

black box — ˌblack ˈbox noun [countable] informal 1. an electronic unit that records information on an aircraft about its height, speed etc. If the plane crashes, the black box can be examined to find the causes: • Data from the black box recovered from the… … Financial and business terms

Black Box — oder Blackbox (engl. blæk bɒks ‚schwarzer Kasten‘) steht für: Black Box (Systemtheorie), ein geschlossenes System unter Vernachlässigung des inneren Aufbaus, siehe dort auch zur Wortherkunft einen dunklen und schallisolierten Raum, siehe Camera… … Deutsch Wikipedia

black box — black boxes 1) N COUNT A black box is an electronic device in an aircraft which records information about its flights. Black boxes are often used to provide evidence about accidents. 2) N COUNT: usu sing You can refer to a system or device as a… … English dictionary

Black box — (bl[a^]k b[o^]ks ), n. 1. any electronic instrument or part of an instrument whose function is defined, but which is treated as a unit without consideration of the internal mechanisms; broadly, any device whose internal workings are considered as … The Collaborative International Dictionary of English

black box — black′ box′ n. 1) elo any unit that forms part of an electronic circuit and has its function but not its components specified 2) cvb any small, usu. black, box containing a secret, mysterious, or complex mechanical or electronic device 3) aer.… … From formal English to slang

black box — theory … Philosophy dictionary

black box — n informal a piece of equipment on an aircraft that records what happens on a flight and can be used to discover the cause of accidents = ↑flight recorder … Dictionary of contemporary English

Black box что это

В предыдущей статье мы рассмотрели особенности тестирования «серого ящика» по сравнению с «белым» и «черным». Давайте сегодня подробнее остановимся на «черном ящике» и выясним, где и когда его используют, а также какие у него достоинства и недостатки.

Так называемое «black-box тестирование» является методом тестирования программного обеспечения, внутренняя структура, дизайн и реализация которого неизвестна тестировщику (при подготовке тест-кейсов он опирается на требования и спецификацию). Хочу обратить внимание на то, что требования и спецификация не всегда существуют в письменном виде; тем не менее, при тестировании методом черного ящика мы можем опираться на устно описанные требования.

Что такое «черный ящик» согласно терминологии ISTQB?

Где используется метод «черного ящика»?

1. Интеграционное тестирование.
Тестирование, в котором программные и аппаратные компоненты объединяются и тестируются для оценки взаимодействия между ними. При использовании метода «черного ящика» тестировщик проверяет, корректно ли работают все компоненты в целом тогда, когда они интегрированы в большую систему. И действительно, нормальная работа каждой составляющей по отдельности – это еще не гарантия того, что они будут работать вместе в рамках всего проекта. Например, данные могут не отправиться через интерфейс, или интерфейс не отработает согласно документации. При планировании таких тестов тестировщики опираются на спецификацию.

2. Функциональное тестирование.
Используя этот метод, тестировщик проверяет, выполняет ли программное обеспечение все заявленные функции и требования клиента в полном объеме согласно документации.

3. Стресс-тестирование.
Предположим, что у нас есть букмекерская онлайн-контора, в документации к которой заявлена возможность одновременной регистрации 1000 пользователей. В этом случае стрессовым тестированием будет непрерывный поток автоматизированных регистраций (как минимум, 1000 регистраций в минуту) на протяжении 12 часов.

4. Usability-тестирование.
Пусть в упомянутой букмекерской конторе есть функционал «Купон»: мы проверяем, сколько времени уходит у пользователя для добавления ставки в купон, ввода суммы и завершения ставки.

5. Тестирование производительности.
Таким видом тестирования мы можем проверить: есть ли утечки памяти, насколько быстро система работает и выдает обратную связь, не потребляет ли наше ПО слишком много трафика и не создает ли избыточное количество подключений.

6. Приемочное тестирование.
После проверки ПО тестировщиками его отдают заказчику, который запускает приемочные тесты «черного ящика» на основе ожиданий от функциональности. Как правило, набор тестов в этом случае определяет сам заказчик, за ним же остается право отказаться от приемки (если его не устроили результаты тестирования).

7. Регрессионное тестирование.
Проводится на протяжении всего цикла разработки. Цель такого тестирования – проверить работоспособность нового кода и выяснить, не привел ли он к ошибкам или поломкам в старом функционале.

• делаем репрезентативную выборку тестов, в которой используются все функции ПО;
• выбираем тесты, сосредоточенные на программных компонентах/функциях, которые подверглись изменениям;
• используем дополнительные тестовые примеры, уделяя основное внимание функциям, на которые с наибольшей вероятностью повлияли изменения.

Хочу обратить ваше внимание на то, что регрессионное тестирование не всегда проводится только методом «черного ящика»; для регресса также используется метод «белого ящика», особенно при поиске функций, на которые с большой вероятностью повлияли изменения.

8. Beta-тестирование.
Это тестирование также проводится методом «черного ящика». Практически готовое ПО отдают для «обкатки» желающим для выявления максимального количества ошибок еще до того, как оно попадет к конечному пользователю.

• идентификацию непредвиденных ошибок (так как бета-тестеры используют ПО нестандартно);
• широкий набор окружений для проверки, который трудно обеспечить иными методами (разные операционные системы, разные настройки, разные версии браузеров);
• снижение расходов (так как работа бета-тестеров, как правило, не оплачивается).

Техники тестирования «черным ящиком»

1. Эквивалентное разбиение.
Эта техника включает в себя разделение входных значений на допустимые и недопустимые разделы и выбор репрезентативных значений из каждого раздела в качестве тестовых данных. Она может быть использована для уменьшения количества тестовых случаев. Допустим, у нас есть целая переменная N в диапазоне от -99 до 99: позитивными классами эквивалентности будут [-99, -10], [-9, -1], 0, [1, 9], [10, 99], а недействительными (негативными) – <-99, >99, пустое значение, нечисловые строки.

2. Анализ граничных значений.
Техника, которая включает в себя определение границ входных значений и выбор в качестве тестовых данных значений, находящихся на границах, внутри и вне границ. Многие системы имеют тенденцию вести себя некорректно при граничных значениях, поэтому оценка значений границ приложения очень важна. При проверке мы берем следующие величины: минимум, (минимум-1), максимум, (максимум+1), стандартные значения. Например, в том же случае -99 <= N <= 99 будет использоваться набор: -100, -99, -98, -10, -9 -1, 0, 1, 9, 10, 98, 99, 100.

3. Тестирование таблицы переходов.
При данной технике сценарии тестирования выбираются на основе выполнения корректных и некорректных переходов состояний. Допустим, мы хотим записаться на прием к врачу и зарезервировать время своего приема: заходим в форму, выбираем удобное для нас время и нажимаем кнопку «Записаться». Сразу после этого выбранное нами время становится недоступно для другой записи, так как первая запись привела к изменению в базе.

4. Тестирование по сценариям использования.
Эта техника используется при написании тестов для индивидуального сценария пользователя с целью проверки его работы.

Достоинства метода

• Тестирование методом «черного ящика» позволяет найти ошибки, которые невозможно обнаружить методом «белого ящика». Простейший пример: разработчик забыл добавить какую-то функциональность. С точки зрения кода все работает идеально, но с точки зрения спецификации это – сверхкритичный баг.
• «Черный ящик» позволяет быстро выявить ошибки в функциональных спецификациях (в них описаны не только входные значения, но и то, что мы должны в итоге получить). Если полученный при тестировании результат отличается от заявленного в спецификации, то у нас появляется повод для общения с аналитиком для уточнения конечного результата.
• Тестировщику не нужна дополнительная квалификация. Часто мы пользуемся различными сервисами и приложениями, не очень в них разбираясь. Для того, чтобы открыть инстаграм и обработать свою фотографию, нам совсем не нужно знать способ реализации фильтров. Мы хотим открыть фотографию, выбрать фильтр и получить красивую картинку на выходе. Задача тестировщика, который тестирует эту функцию в инстаграм, – убедиться, что пользователь получит эту самую красивую картинку в соответствии с выбранным фильтром. При этом нам совсем не обязательно иметь какую-либо специализацию – нужны лишь телефон и инстаграм.
• Тестирование проходит «с позиции пользователя». Пользователь всегда прав, он конечный потребитель практически любого ПО, а значит, ему должно быть удобно, комфортно и понятно.
• Составлять тест-кейсы можно сразу после подготовки спецификации. Это значительно сокращает время на тестирование: к тому моменту, как продукт готов к тестированию, тест-кейсы уже разработаны, и тестировщик может сразу приступать к проверке.

Недостатки метода

• Основным недостатком метода «черного ящика» является возможность пропуска границ и переходов, которые не очевидны из спецификации, но есть в реализации кода (собственно, это и заставляет тестировщиков использовать метод «белого ящика»). Вспоминается случай, когда система получала котировки валют с биржи Forex и округляла до 3 знаков после запятой. Система успешно прошла тестирование методом «черного ящика» (так как ни одна валюта не выходила за соответствующие границы) и хорошо работала до тех пор, пока курс доллара к биткоин не вышел за границы 1000 долларов. Тестирование «белым ящиком» выявило бы ошибку: специалист увидел бы, что коэффициент конверсии валюты ограничен 3 знаками.
• Можно протестировать только небольшое количество возможных вводных (входящих) значений; многие варианты остаются без проверки.
• Тесты могут быть избыточными, если разработчик уже проверил данную функциональность (например, Unit-тестом).
• При отсутствии четкой и полной спецификации проектировать тесты и тест-сценарии оказывается затруднительно.

Подведем итоги

Из представленной информации мы можем сделать следующий вывод: метод «черного ящика» является эффективным при различных видах тестирования; но следует помнить, что некоторые ошибки невозможно найти, используя только этот метод (например, ошибки во внутренней структуре кода).

Проведение «black-box» тестирования увеличивает уверенность в том, что приложение надежно работает на широком диапазоне входных данных, так как набор тестовых данных зависит только от спецификации, а не от особенностей внутренней реализации продукта (как в случае применения методов «белого» и «серого» ящиков).