Фраза “перемены постоянны” не нова, и сегодня в мире технологий она верна как никогда. Внедрение новых технологий, продуктов и услуг, усовершенствование существующих решений или вывод из эксплуатации того, что больше не является жизнеспособным, – все эти вещи представляют собой изменения в нашем техническом ландшафте.
Согласно последним исследованиям, до 80 % крупных инцидентов вызваны изменениями. Сбор данных о показателях успешности и инцидентах, вызванных изменениями, важен для понимания сильных и слабых сторон вашей деятельности.
Вот несколько вопросов, которые следует рассмотреть:
- Каков коэффициент успешности изменений в вашей организации?
- Измеряете ли вы инциденты, вызванные изменениями?
- Они произошли из-за изменений или спровоцированы изменениями? В чем разница?
- Есть ли команды, которые более успешны, или приложения, которые более устойчивы?
- Используете ли вы автоматизацию?
Существует множество составляющих успешной среды изменений, но, не изучив сначала данные, чтобы понять, как вы работаете, вы никогда не узнаете, с чего начать. Если вы смотрите на эти показатели и можете выявить тенденции, то вы можете начать разрабатывать дорожную карту для создания более стабильной среды. Хотя предотвратить 100 % инцидентов при внедрении изменений невозможно или нереально, более глубокое изучение процессов изменения, анализа, тестирования и внедрения может помочь улучшить эти показатели и понять, где лежат возможности для улучшения.
Роль коммуникации и прозрачности
Начиная с планирования и заканчивая внедрением, решающее значение для успеха любого изменения имеет коммуникация. Зачастую координация между командами при внедрении существует, но она может быть слишком узконаправленной. При формировании требований необходимо убедиться, что зависимые приложения, как минимум, осведомлены об общем характере предстоящего изменения.
Также важно убедиться в том, что ваши команды, отвечающие за базовую инфраструктуру, понимают, какое влияние окажет изменение на их среду. Если вы ожидаете увеличения объема или количества обращений за услугами, вам необходимо понять значимость разницы и сообщить об этом своим службам поддержки. Неожиданный приток трафика может вызвать хаос в системах поддержки и оказать остаточное влияние на другие приложения. Эти команды должны не только знать о ваших изменениях, но и участвовать в тестировании.
Сотрудники контакт-центров, агенты сервис деска и другие коллеги, работающие с приложениями, также должны знать об элементах изменений, касающихся любых пользовательских интерфейсов. Меняются ли при этом рабочие процессы? Обеспечьте наличие ресурсов, которые помогут сориентировать сотрудников и определить их ожидания, а также предоставить информацию о том, что делать, если что-то выходит за рамки этих ожиданий. Чем лучше сотрудники будут осведомлены об изменениях и ожиданиях от них, тем меньше будет “шума” после изменений, что позволит командам сосредоточиться на мониторинге после внедрения, чтобы обеспечить более гладкий опыт для всех.
Тестирование
Тщательное тестирование – один из лучших способов убедиться, что изменения идут по плану. Юнит-тестирование, регрессионное тестирование, тестирование производительности, пользовательское приемочное тестирование – чем более зрелым и надежным будет ваш план тестирования и среды, тем меньше шансов на серьезный инцидент после внедрения.
В идеале для тестирования производительности непроизводственные среды должны иметь размер “как в производстве”. Объемы транзакций также должны по возможности соответствовать ожидаемым объемам производства. Кроме того, при тестировании производительности, обзорные встречи до и после изменений могут иметь решающее значение для выявления неожиданного поведения. Не показывают ли ваши вспомогательные среды значительные изменения в потреблении ресурсов после изменения? Лучше знать и понимать это сейчас, на этапе подготовки к эксплуатации.
Тестовые сценарии как для автоматизированного, так и для ручного тестирования должны включать тестирование на наличие ошибок и их обработку. Если вы будете тестировать только “счастливый путь”, то, скорее всего, столкнетесь с проблемами, когда путь отклонится от этих конкретных сценариев. По мере того, как все больше организаций переходят на более гибкую скорость реализации проектов, автоматизация тестирования может стать очень полезным и мощным подспорьем в обеспечении того, чтобы ваша основная функциональность оставалась в рабочем состоянии, и облегчить нагрузку на ручное тестирование. Мы, вероятно, все видели мемы о тестировании в живой среде, но никому не нравится опыт работы с крупными инцидентами, которые происходят из-за неадекватного тестирования.
Дополнительные соображения
Мы уже говорили о преимуществах автоматизации тестирования, но и код, развернутый с помощью автоматизации, с меньшей вероятностью будет подвержен человеческим ошибкам. Автоматизация развертывания кода может быть протестирована в разных средах, что повышает вероятность успеха. Кроме того, следует протестировать и процесс отката развертывания. Как мы уже говорили, невозможно гарантировать 100-процентный успех изменений, поэтому важно, чтобы в дополнение к тестированию вне “счастливого пути” мы планировали и тестировали откат кода, если он понадобится в случае непредвиденных обстоятельств.
И наконец, давайте рассмотрим разницу между инцидентами, «вызванным изменением» и «спровоцированным изменением». В момент инцидента они могут выглядеть синонимами, но это не так.
Важно понять, вызвал ли проблему какой-то элемент изменения или его реализация, или же она выявила что-то еще в среде. Если это последнее, то инциденты, спровоцированные изменениями, могут вызывать разочарование, поскольку часто в среде есть элементы, которые не были поняты или не могли быть протестированы в предпроизводственной среде, потому что их там не было; также возможно, что причиной неполадки стала нестабильность среды после системной перезагрузки для завершения внедрения изменений. В этих случаях нет никакого элемента изменения, который был бы виноват, а есть только событие, предшествовавшее инциденту. Опять же, наличие тщательно протестированной процедуры отката может стать решающим фактором для быстрого восстановления системы в случае непредвиденных обстоятельств.
Мы затронули несколько элементов, которые в значительной степени способствуют успеху изменений; есть и другие, но прочный фундамент – это всегда отличное начало. В зависимости от размера вашей организации и имеющихся ресурсов, вы можете быть ограничены в некоторых из этих элементов, но размышления и анализ помогут вам определить, где у вас все же есть возможности. И если вы можете определить, как ваша организация может улучшить качество изменений, то зрелость процессов и ресурсов, скорее всего, последует за этим.
