На наших учебных курсах и семинарах по DevOps мы время от времени проводим упражнение, в котором участники, работая в командах, стараются составить список сложностей и ограничений, присущих DevOps. Пункты списка должны быть обоснованы, точка зрения аргументирована. Наиболее полезным такое упражнение является для корпоративных групп, состоящих из сотрудников одной организации.
При этом интересно, что в течение предшествующих одного-двух дней обучения, при рассмотрении сути и практик DevOps, группа называет сложности, которые кажутся очень серьёзными. Зачастую – просто непреодолимыми. Однако типичный список на выходе “финального” упражнения не такой уж и страшный:
- Отсутствие необходимой культуры, иная корпоративная культура
- Инертность организации, необходимость организационных преобразований
- Сложности с организацией сотрудников в команды, выделение времени, физическое размещение
- Разобщённость бизнеса и ИТ, нет работы на общий результат
- Регуляторные ограничения (включая безопасность, SOX, compliance…)
- Привлечение сторонних разработчиков ПО, программисты вне штата компании
- Расходы, связанные с организацией DevOps (обучение, инструменты, увеличение штата)
- Уже имеющиеся сложные ИТ-системы с большим числом связей
- Негативный опыт применения гибкой разработки, неоправдавшиеся надежды, скромный полученный результат от Agile
- Большая доля ручного труда, отсутствие достаточного количества тестов, низкая культура разработки ПО
- Сложности разделения работы на небольшие части
- Привычка всё тщательно планировать, обосновывать, согласовывать, только затем делать
- Многозадачность как норма
Понятно, что список можно продолжать, но я намеренно остановился на числе 13.
Итак, первое наблюдение – большинство пунктов такого списка не являются непреодолимыми препятствиями. К ним можно относиться как к управленческим задачам, требующим решения. Собственно, вторая часть упражнения как раз и состоит в нахождении способов устранения или смягчения ограничений. Например, насколько действительно невозможно изменить пункт 3 – организовать такие команды, которые будут способны работать эффективно? Насколько долго и дорого пересмотреть пункт 10, кардинально уменьшив долю ручного труда и повысив культуру разработки программного обеспечения? Так же и далее, по многим пунктам. Постепенно в ходе дискуссии становится понятно, что настоящих ограничений, останавливающих или делающих невозможным применение идей DevOps, не так уж и много, и вот с ними-то придётся тщательно разбираться.
Второе наблюдение – многие пункты такого и подобного списков не являются чем-то специфичным для DevOps. Действительно, разве не приходится думать про корпоративную культуру при выполнении любых значимых преобразований, затрагивающих работу ИТ? Разве не мешают нам ограничения со стороны, скажем, информационной безопасности, реализовывать ITSM-инициативы?
Выполняя такое упражнение с разными командами, нам пока не удалось найти организацию, где DevOps принципиально невозможен. А все случаи, когда DevOps будет сделать очень трудно, пока не выходят за рамки описанных в книге.
