В статье описываются некоторые проблемные моменты, связанные с развертыванием программного обеспечения на крупных IT проектах, а также указаны некоторые рекомендации из числа лучших международных практик. Рассмотренные вопросы затрагивают проблемы IT методологии, которая активно развивается в последнее время.
1 Фактическая ситуация развертывания ПО
В данный момент одним из самых быстроразвивающихся направлений в IT индустрии является наладка и обеспечение непрерывной доставки ПО Заказчику с помощью разнообразных комбинаций технологий и инструментов. Новые требования к развертыванию ПО, продиктованные развитием технологий и методологий разработки, включают в себя постоянную готовность и непрерывность тестирования изменений, подготовку и настройку тестовой среды для команды обеспечения качества. Кроме того, постоянное технологическое развитие сделало возможным и доступным большое количество сервисов, аппаратного обеспечения, которые ранее не рассматривались для использования в производстве. Таким образом данный технологический прорыв, а также успех свободно распространяемого ПО, привели к тому, что стоимость владения аппаратными и программными ресурсами, в многих случаях стала меньше чем стоимость труда квалифицированного IT специалиста. Также значительно изменился подход к организации процесса непрерывной доставки ПО. В данной статьи будут рассмотрены основные тенденции в поддержке и сопровождении процесса разработки в современных реалиях.
Рассмотрим один из типичных случаев при настройке серверов приложений для тестирования и отладки разрабатываемого ПО. Используется несколько уникальных серверов, на которых тестируются все изменения и производятся пусконаладочные работы. Данные сервера настроены вручную, все изменения в конфигурации сервера, а также все изменения, связанные с установкой и настройкой разрабатываемого ПО, не регистрируются. В подавляющем большинстве случаев развёртывание приложения осуществляется представителем команды разработки, который имеет неограниченный доступ к серверам. Процесс доставки лишь отчасти можно назвать непрерывным, так как в него вовлечены представители всего двух команд: тестирования и разработки, проблемы решаются путем тесного взаимодействия между командами, преимущественно неформального. Рассмотрим некоторые риски, присущие данному подходу к организации процесса развертывания ПО.
2 Анализ риска
Первый и самый существенный риск связан с человеческим фактором. Представим себе ситуацию, когда необходимо настроить ещё несколько серверов, аналогичных существующим. Если специалист, который производил предыдущие установки или настройки в данный момент недоступен по каким-либо причинам (болен, уволился и т. д.) и не подготовил подробных инструкций, то ситуация значительно осложняется. В этом случае каждый новый специалист должен пройти весь процесс настройки сервера полностью, при этом у него нет права на ошибку. В результате будет потрачено неопределенное количество времени на настройку, при этом результат не может быть на 100 % успешным, так как все работы будут вручную. Кроме того, может потребоваться тщательное тестирование сервера перед установкой ПО, дабы исключить наложение ошибок, связанных с настройкой системы и ошибок, связанных с работой тестируемого ПО. При необходимости повторить настройку сервера все трудозатраты, а также необходимое время, остаются высокими и меняются незначительно, так как большинство действий не автоматизировано. [1]
Второй риск также является прямым последствием большого объёма ручного труда требуемого для настройки сервера. Речь идёт о регистрации изменений, вносимых в конфигурацию сервера, в лучшем случае они будут подробно отображены в инструкции, в худшем всегда будет вероятность того, что конкретный специалист внесёт изменения в конфигурацию и забудет отобразить эти шаги в инструкциях. Данный риск возрастает многократно при применении критических исправлений, внеочередных патчей и так далее. Из-отсутствия регистрации изменений, найти и откатить неудачное обновление будет весьма проблематично, особенно если откат нужно будет произвести спустя некоторое время, так как возможно наложение других изменений, также произведенных вручную.
Третий риск аналогичен второму, он также связан с регистрацией изменений, с той лишь разницей, что речь идет об изменениях в установленном ПО для тестирования. Иначе говоря, необходимо точно знать, какая сборка ПО установлена на конкретном сервере, а также нужно иметь возможность откатить установку конкретной сборки на сервере. В случае отсутствия системы автоматизированного развертывания ПО, можно наблюдать все негативные последствия, описанные выше, с той лишь разницей, что некорректные изменения в конфигурации сервера и в установленном ПО, суммарно могут дать непредсказуемый эффект. Таким образом многократно возрастает вероятность получения заведомо нерабочей системы, трудно поддающейся диагностике.
3 Предложение по автоматизации развертывания ПО
Резюмируя вышесказанное, стоит отметить, что обозначенные риски возрастают многократно при повышении интенсивности процесса разработки, так как в свою очередь возрастает нагрузка на команды тестирования, внедрения и сопровождения. Альтернативой описанному выше подходу является построение непрерывного конвейера по доставке разрабатываемого ПО Заказчика с использованием специализированных технологий и методов. Рассмотрим основные рекомендации, используемые при таком подходе.
1.1 Использование IT-Management Tools
Первым важным шагом является отказ от отношения к серверам, как трудно настраиваемому, уникальному элементу инфраструктуры, переход от ручной настройки сервера к автоматизированному, централизованному управлению инфраструктурой. Таким образом процесс настройки каждого сервера должен быть описан в виде конфигурации, легко читаемой и изменяемaой. Примерами промышленных систем-оркестраторов являются Chef, Ansible, Microsoft PS DSC. Данные системы позволяют управлять большим количеством серверов с минимальными затратами.
Следующим важным шагом является применения автоматизированного тестирования для как можно большего покрытия функционала разрабатываемого кода. Иначе говоря, имея развернутую инфраструктуру, но без автоматизированного тестирования, узким местом процесса разработки будет своевременная проверка функционала. Автоматизирование процесса тестирования должно начинаться с собственно написания кода ПО (unittest), применение первичных тестов на сервере, отвечающим за сборку ПО, а также тест конфигурации серверов. Это позволит снизить нагрузку на команду обеспечения качества ПО и значительно снизит время прохождения ПО на конвейере.
Заключительным логичным шагом является централизованный сбор и анализ лог-файлов со всех серверов, для своевременного оповещения всех заинтересованных лиц и проактивном наблюдении за состоянием инфраструктуры в целом.
Следование перечисленным выше рекомендациям позволит построить устойчивую, масштабируемую инфраструктуру, способную работать в интенсивном процессе разработки. Рассмотрим несколько примеров, чтобы понять преимущества данного подхода.
Первый типичный случай: команда разработки запросила ещё одну группу серверов приложений для отладки новой сборки приложений, при этом все существующие сервера используются для отладки и тестирования текущей сборки, но разработчики планируют переход на новую сборку в скором времени. При первом подходе необходимо будет произвести ручную настройку новых серверов, после этого произвести тестирование конфигурации серверов и наконец произвести установку новой сборки на все сервера. Очевидно, что конечный результат будет целиком и полностью зависеть от профессионализма специалистов, которые будут осуществлять все действия, в строгой последовательности и проверкой каждого шага. Также необходимым условием для успешного выполнения данной задачи является наличие полных и актуальных инструкций по настройке серверов. При втором подходе ручная работа сводится к разворачиванию типового образа сервера, и применении скриптов автоматической конфигурации, от лица централизованной системы-оркестратора. Так как скрипты и конфигурации являются типовыми и проверенными на других серверах, то вероятность получения ошибки сводится к минимуму. Временные затраты при данном подходе также сводятся к минимуму.
Второй случай: в результате применения нескольких изменений в конфигурации сервера приложений и установки новой сборки, команда тестирования обнаружила ряд проблем, трудно поддающихся диагностике. При первом подходе надо последовательно откатывать вручную все изменения на сервере, а также параллельно тестировать как эти изменения влияют на установленное ПО. Данный процесс должен продолжаться до тех пор, пока не будет найден источник проблем. Создание данного сервера «с нуля», в целях устранения эффекта наложения изменений, не рассматривается, ввиду больших временных затрат и большого количества ручного труда. Данный подход в методологии называется «сервер как домашний любимец». При втором подходе сервер создаётся заново, эффект наложения изменений отсутствует, процесс диагностики проблем облегчается за счет применения необходимой версии конфигурации.
Третий случай: потеря группы серверов приложений в результате сбоя. В лучшем случае имеется рабочая проверенная резервная копию сервера, в худшем необходимо создать сервер заново. Как и в предыдущих случаях очевидно, что в стрессовой ситуации вероятность получить 100 % работающий сервер гораздо выше при втором подходе. Возможность создания и настройки сервера приложения с помощью оркестратора и скриптов автоматизации, в данном случае не является заменой традиционному резервному восстановлению, при этом предоставляет интересную альтернативу, которую можно рассматривать частью плана восстановления работоспособности сервисов, инфраструктуры.
1.2 Формализация общения
Как показывает практика внедрения процессов автоматизации в IT производстве, важным залогом успешного результата является правильно построенная модель коммуникаций. В основе данной модели должны лежать несколько важных принципов:
1) Руководителям всех IT команд, принимающих активное участие в процессах автоматизации должны быть описаны все преимущества данного подхода также как и ожидаемые проблемы внедрения. Сотрудник, который является ответственным за коммуникации с руководителями должен в достаточной степени понимать технические особенности процесса автоматизации, а также понимать ценность данного процесса для бизнеса и команд разработки, обеспечения качества. При этом он должен обладать необходимыми личностными качествами, чтобы завоевать авторитет среди руководителей. Таким образом, если руководитель команды будет разделять и понимать ценности процесса, то необходимые изменения будут применены гораздо быстрее, а задержки будут минимальными.
2) Должна существовать матрица коммуникаций, в который четко расписаны роли, контактная информация об участниках процесса автоматизации. В качестве примера можно взять матрицу RACI из ITIL. [3, стр.150–151] Это поможет снизить «усталость» от информационного потока, связанного с большим количеством внедряемых изменений, улучшить обратную связь между командами.
3) В особых случаях координатору проекта необходимо выступать в качестве агитатора, вдохновителя для команд. Это связано с тем, что внедрение изменений как правило сталкивается с определенными психологическими трудностями. [2, стр.7] Необходима ясная цель, ради которой сотрудники будут изменять уже сложившиеся процессы, привычки.
4) Типовые запросы на изменения должны быть стандартизированы с учетом опыта команды внедрения и сопровождения, таким образом, чтобы вся необходимая информация была предоставлена в одном запросе.
5) Необходимо выбрать наиболее подходящие каналы и инструменты коммуникаций для того чтобы обеспечить высокую эффективность передачи информации между всеми заинтересованными лицами. Сюда также относятся различные внутрикомандные вики-системы, предназначенные для систематизирования и упорядочивания информации о программно-техническом комплексе, IT инфраструктуре.
4 Вывод
В данной статье были рассмотрены лишь некоторые подходы к организации процесса развертывания и поддержки инфраструктуры. Очевидно, что описанные выше методы должны опираться на соответствующие методологии организации и управления разработкой и сопровождением ПО. В противном случае любые применяемые технические средства не будут эффективны. Именно поэтому выбор, анализ и применение рекомендаций, описанных в библиотеке ITIL, методик разработки ПО являются краеугольным решением для IT руководства IT. Как показывает практика, большое влияние на развитие современных методологий IT имеет опыт разработки ПО для различных стартапов. Именно они являются достаточно гибкими и открытыми, чтобы применять новейшие технологии и методология для достижения высоких результатов, постоянно решают проблемы масштабирования, поддержки инфраструктуры, мониторинга ПО, организации эффективной внутрикомандной коммуникации. Разнообразие облачных ресурсов позволяет применить наиболее продвинутые методы по развертыванию инфраструктуры, снизить производственные риски. В качестве примера можно рассмотреть стандартные инструменты для масштабирования инфраструктуры в AWS и Azure. Без автоматизации практически невозможно реализовать необходимость корректного масштабирования серверов приложений, серверов БД. Таким образом стандартная задача в рамках автоматизации облачной инфраструктуры, является трудновыполнимой для команды, работающей без применения DevOps практик.
Если говорить о проектах национального масштаба, стоит отметить, что использование Agile методологии, внедрение DevOps практик затруднено из-за некоторых объективных причин:
– Определенная модель бюджетирования, более подходящая для Waterfall методологии
– Высокие требования к безопасности, следовательно невозможность размещения инфраструктуры национальных IT проектов в зоне ответственности коммерческих, иностранных компаний, например Amazon, Microsoft.
– Высокий объем “legacycode”, “legacyinfrastructure”, которые необходимо поддерживать. Необходимость интеграции с большим количеством устаревших систем.
Тем не менее, стоит рассматривать вышеперечисленные подходы к организации производственного процесса на IT, как реальную, проверенную практикой альтернативу классическим методам.
Литература:
- The DevOps Collective — [Электронный ресурс]. https://devopscollective.org/2016/03/23/a-plea-for-idempotence-and-immutability/ — (дата обращения: 21.04.2016).
- DevOps in Practice, J. Paul Reed. — O’Reilly Media, Inc. 2014–25p.
- Liz Gallacher, Helen Morris. ITIL Foundation Exam Study Guide. —John Wiley & Sons. 2012–320p.
