Комментарии 5
Ох. Спасибо за грамотный и осмысленный рассказ о немаловажных вещах. Полностью согласен - чем проще будет документ декларирующий цели, тем проще будет путь к ним.
Спасибо, что поделились примером топологии, таких примеров еще мало и всегда интересно изучать:
Я правильно понимаю, что топология похожа на ту, которая у вас сейчас в компании?
Видите ли вы проблемы с тем, что слева и справа от stream-aligned команд есть департаменты ИБ и сопровождения? не является ли это примером тех самых "высоких и толстых стен"?
Почему не используете в топологии "официальные" способы взаимодействия (collaboration, x-as-a-service, facilitating)?
Видите ли вы пересечения между задачами/активностями IT-сообществ и enabling командами?
Спасибо за прочтение статьи и вопросы. 😊
Топология, представленная в статье, является одним из примеров, когда между dev и ops есть различные ограничения ввиду требований ИБ и, в целом, финансовой составляющей. Одна из важнейших наших целей – это создание полноценных и самодостаточных команд, направленных на создание ценностей с выделением из них различных платформенных или сервисных частей. Да, топология из статьи похожа на нашу, но имплементация может быть немного разной (см. ответ на третий вопрос).
Как следствие из ответа на первый вопрос нужно отметить, что не важно, где фактически находится человек, а важно чтобы он понимал и осознал свою принадлежность к команде и, как я отмечал в статье, ответственность за создаваемый им продукт. Это можно заметить на изображении примера топологии, где экспертиза и сами сотрудники из команд ops и sec интегрированы в stream-aligned. Поэтому, если строить такую модель и культуру, то “высоких и толстых стен” в корне не будет. Да, несомненно, если этот подход не соблюдать и за ним не следить, то кирпичики кто-то начнет ставить.
Из-за гетерогенности среды, а также ввиду нашего “двухскоростного ИТ*” мы применяем различные типы взаимодействия команд, в том числе collaboration, x-as-a-service, facilitating, но конечно же с проекцией на наши процессы и особенности.
*"«Первая скорость» подразумевает, что мы обеспечиваем надежность и доступность ключевого бизнеса. Мы не можем применять здесь гибкие методы разработки, иначе потеряем в надежности. Но, с другой стороны, когда идешь в сегмент ритейла, нужно постоянно пробовать новые продукты. Поэтому «вторая скорость» подразумевает эксперименты". (подробнее на tadviser.ru).
Для ответа на четвертый вопрос, давайте посмотрим на цели ИТ-сообществ и команды-драйвер (или enabling team). Цели сообществ – это “ускорение принятия решений, сокращение времени доставки ценностей, а также развитие экспертизы сотрудников, обучение и личностный рост”, а enabling team – это помощь командам в решении проблем и задач, для ускорения принятия решений и сокращение времени доставки ценностей. Вывод: цели глобально совпадают, поэтому, да, между ними есть пересечение активностей. Порой, даже команды-драйверы или люди-драйверы могут выявляться именно из сообществ и помогать другим.
Всё правильно, полностью согласен.
DevOps: о самом важном. Часть 1. Про то, о чем мало говорят