19.07.2024. Новости (правда, зарубежные, в основном) пестрят сообщениями о глобальном сбое в ИТ системах международных компаний.
Но где же настоящий сбой и что им реально явилось?
Причина, как заявляют, связана с американской фирмой по кибербезопасности CrowdStrike - она выпустила обновление, которое привело к сбоям в Windows — приложение отключает персональные компьютеры и серверы от сети, заставляя их переходить в цикл восстановления, и систему невозможно запустить должным образом. А пользователи жалуются на появление «синего экрана смерти» на устройствах с Windows 10.
Немного другой взгляд:
Сбой начался накануне из-за «изменения конфигурации в части наших внутренних рабочих нагрузок Azure» облачных вычислений Microsoft, которое «вызвало перебои между ресурсами хранения и вычислений, что привело к сбоям подключения, ...».
Но это всё НЕ причины. Это какие-то локальные дефекты, а кризис-то затронул бизнес, почти весь мир. Не тестовый стенд с имитацией Земли, а самый что ни на есть настоящий мир, с аэропортами, телекомпаниями и реальным сектором экономики.
И вопрос не в том, что какая-то компания выпустила продукт с критическим и даже с блокирующим дефектом - такое бывает. Нет, надо признать, что продуктов БЕЗ дефектов не бывает. Практически не бывает. Но сам по себе дефект это только первый шаг, а к сбоям систем приводят не столько дефекты, сколько ошибки.
В чём разница?
Дефекты
Все ли компании имеют отделы тестирования (испытаний)? А все ли имеют эффективные процессы этих тестов? На собеседованиях инженеров по тестированию я спрашиваю - а какой KPI у отдела тестирования?
KPI - это цифровой показатель эффективности для бизнеса. Конечно, метрика скорости выполнения задач это тоже KPI, но он актуален для всех. Уникальный KPI для функции QA - это точно не количество найденных дефектов.
Что такое дефект продукта?
- это любая его характеристика, которая препятствует использованию продукта в заданных для него целях.
- Это несоответствие характеристик продукта Техническому Заданию.
Если у вас есть лампочка и включатель, которые соединены и имеют функции включить и выключить свет от лампочки, то шансы создать там дефект при наличии профессионального электрика стремятся к нулю, и KPI тестировщика недостижим - они там практически никогда ничего не найдут.
А если перед вами огромный комплекс сложных взаимосвязанных систем, то шанс, что дефектов не будет - 0.
На мой взгляд, показатель эффективности QA - количество дефектов, найденных пользователями, но не найденных тестировщиками = 0.
И если оно больше нуля - значит, что что-то не так в процессах QA, надо улучшать.
Ошибки
Дефект в продукте затронул боевые системы, и они упали, показав всем фигу синий экран смерти.
Вопрос - а как так построены службы и процессы реальных компаний, что дефект стороннего ИТ продукта парализовал весь бизнес?
Т.е. племя шло, шло и шло по лесу, и тут все видят новый гриб, который ещё никто не пробовал - знаете, такая, например, лисичка, но красная. Или синяя. Или растущая на дереве.
Шаман и говорит всему племени - О, это боги провели очередной апдейт продукта, и просто его немного модернизировали, давайте-ка мы его все дружно съедим.
Не дадим попробовать одному, чуть-чуть, не потренируемся на кошечках - а сразу в бой! Сожрём этот новый гриб все сразу, наварим из него суп, а завтра все дружно узнаем (или уже не узнаем) последствия...
Кажется, в современном мире нормальные люди так не делают, а если и делают - то очень ограниченное количество раз.
Тогда почему? Почему процессы компаний-потребителей различных ИТ продуктов и услуг не принуждают вначале тестировать апдейты в песочнице, только после тестов добавлять в доступное хранилище для скачивания и устанавливать запрет на выход систем в дикий интернет?
Это не какой-то одинокий дефект, что вызвал сбой на рабочем ПК. Это явная разруха в подходе к продакшн, к разумным, накопленным за поколения требованиям к запуску новых решений в бизнесе (а не в каком-то одном поставщике), всеобщему доступу систем к некорпоративным хранилищам обновлений.
Один большой мировой АВОСЬ.
