Чтобы определить, является ли сбой RAID-массива инцидентом, нужно учитывать конкретную конфигурацию и условия, при которых массив считается работающим нормально. Например, в RAID 1+0 выход из строя одного диска в зеркале не считается инцидентом, если это не влияет на функциональность массива и его отказоустойчивость остается в допустимых пределах. Однако выход из строя второго диска в том же зеркале может привести к потере надежности и уже будет инцидентом. Важно определить, какие состояния являются нормальными для конкретной системы на основе технических спецификаций, и только после этого принимать решение о классификации происшествия.

Примеры успешного фокуса на результатах: магазин, внедривший ИИ-аналитику (выход), который смог составлять персонализированные предложения и увеличить средний чек на 17% (результат); компания Ford, заменившая KPI 'количество строк кода' на 'снижение времени сборки авто', что повысило эффективность ИТ на 200%; внедрение чат-бота, приведшее к сокращению затрат на поддержку на 500 000 рублей в год и повышению удовлетворенности клиентов. Во всех случаях внимание было сфокусировано на конечных бизнес-результатах, а не только на технических показателях.

Термин OLA может быть избыточным, потому что содержательно OLA не отличается от SLA, а является всего лишь SLA с другой стороны. Если рассматривать цепочку создания ценности, то то, что для одного участника выглядит как OLA, для другого будет SLA. Примеры из ITIL Service Design показывают, что предлагаемые SLA и OLA очень похожи. Поэтому OLA как отдельная концепция не добавляет ценности и может только запутать при реализации, так как теряет четкое определение и аргументированное обоснование, что и приводит к путанице в практическом применении.

Да, все простои, даже если они согласованы и вынесены в отдельное 'окно', должны регистрироваться и фиксироваться как отдельные события. Это связано с тем, что такие простои всё равно происходят вне базового календаря плановых технических окон. Регистрация всех согласованных простоев позволяет обеспечить прозрачность отчётности, корректно анализировать влияние изменений на доступность услуг и избежать ситуации, когда постоянные согласования дополнительных окон фактически заменяют основной календарь плановых работ, превращая его в 'неконтролируемый хаос', как указано в тексте.

Соблюдение правил перемещения задач в канбане важно, потому что именно они определяют логику потока работ и обеспечивают работу вытягивающей системы. Без чётких правил перемещения невозможно контролировать загруженность этапов, выявлять узкие места и поддерживать ограничения WIP. Это приводит к тому, что процесс становится непредсказуемым, возникает эффект "накопления задач" и снижается общая прозрачность работы команды.

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

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

Настройка middleware считается важной компетенцией для внутренней команды, потому что именно она определяет, насколько эффективно и безопасно приложение будет работать в условиях реальной нагрузки и специфики бизнес-процессов. Middleware требуется глубокая экспертиза по настройке под конкретную нагрузку, взаимодействие различных компонентов и обеспечение безопасности. Стандартные решения, предоставляемые IaaS или SaaS, не учитывают специфику продукта, поэтому настройка и конфигурирование middleware остаются внутренней ответственностью. Без этой экспертизы, даже при наличии качественной базовой инфраструктуры, продукт не сможет функционировать должным образом, особенно если речь идет о кастомизированном решении или высоконагруженной системе.

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

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