Привет, Хабр! И снова на связи Алексей Приставко.

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

Слаженная работа этих служб — залог успешного запуска и ровного «полёта» создаваемого сервиса. Но, как показывает мой (и не только) опыт, практически ни один проект не обходится без конфликтов и разногласий, жертвой которых становится ни в чем не повинный сервис.

В этой статье я постараюсь ответить на следующие вопросы:

  • Как методы и процессы разработки отражаются на эксплуатации?
  • Что движет каждой стороной конфликта?
  • В чем первопричина разногласий?

Добро пожаловать под кат!

Какие задачи стоят перед службами


Познакомимся с отделами поближе и начнем со службы эксплуатации (она же служба поддержки). Зачем нужен этот страшный зверь, какую задачу он выполняет и «на кого» работает?

Основная задача службы эксплуатации — это управление уровнем сервисов, то есть поддержание работы IT-системы в рамках SLA.
Эксплуатация должна обеспечивать постоянный доступ к сервису и его корректное функционирование в рамках соглашения с заказчиком — как правило, с бизнесом.

Вот из чего складывается решение этой задачи:

  • Управление инцидентами: восстановление работоспособности бизнес-функции при аварии;
  • Управление проблемами: устранение вероятных причин аварий и инцидентов;
  • Управление конфигурациями: сбор информации и анализ параметров работы ПО и инфраструктуры;
  • Управление изменениями: минимизация риска возникновения проблем и аварий при изменениях.

Роль службы разработки также понятна — первоначальное создание ИТ-сервиса и внедрение в него нового функционала по желанию заказчика.

Наверняка, у вас уже есть подозрения по поводу точек трения разработчиков и поддержки, ведь где возникают пересечения задач, там появляются конфликты. Но не спешите с выводами. Извечные споры разработчиков и админов — это далеко не эпицентр «боёв».

Откуда растут разногласия


«Война» программистов и админов — это не противостояние человеческих интересов, это конфронтация служб.



Проблема заключена в приоритетах и мотивации этих самых служб. В самом общем виде это можно описать так:

  • Команда разработки хочет использовать технологии первой свежести (профессиональное развитие, интерес) и выполнять работу как можно быстрее (внешняя мотивация).

  • Эксплуатация заинтересована в как можно более стабильных технологиях (их проблемы известны и имеют общепринятые решения) и подробных разъяснениях, что им делать в случае возникновения проблем в разработанном ПО (внешняя мотивация на скорость устранения проблем).

При этом важно понимать, что не всегда только разработчики «пилят» новый функционал и не всегда исключительно админы поднимают упавшее.

  • Админы активно участвуют в процессе разработки — в построении инфраструктуры, схем обеспечения отказоустойчивости и масштабируемости, в подготовке первоначальных конфигураций, а в идеале и в процессе подготовки требований к ПО. Всё это называется процессом разработки решения (не путайте с непосредственным написанием кода!).

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

Конфликт между программистами и админами растет из подмены понятий:

  • разработка > написание кода;
  • поддержка > администрирование прикладных сервисов.

Перекос структуры подчинения по профессиональному признаку (а не по функциональному) всегда приводит к конфликтам. Как правило, администраторы и программисты работают в совершенно разных командах, а иногда и отделах, и мотивируются как эксплуатация и разработка соответственно.

В результате программисты из отдела разработки, которых «заставляют» устранять старые баги или, не дай Бог, писать документацию, недовольны. Точно так же негодуют и админы из эксплуатации, которых просят по-быстрому подкинуть рояльчик поднять новый сервак для разработчиков или помочь им советом.

Каждая из сторон воспринимает это не в качестве совместного решения проблемы, а как отвлечение от собственных задач, которым и без того конца и края не видно.

Но нельзя забывать и про заказчика, ведь он, хоть и косвенно, также является участником конфликта. Как правило, ему нужно получить установленный и стабильно работающий сервис. «Голый» код, даже самый хороший, вне системы для заказчика совершенно бесполезен. У него в принципе другая картина мира:



У стандартного заказчика нет задачи что-то создать, написать или, прости, господи, внедрить. Заказчик хочет решить бизнес-проблему с помощью волшебной кнопки «Сделать всё хорошо», в то время как IT навязывает предлагает ему конкретное решение.

Давайте взглянем на все стороны конфликта:



Разумеется, это только самая общая часть функциональных и эксплуатационных требований.

Итак, мы выяснили, что в конфликте все-таки три участника: разработка, эксплуатация и заказчик. Причем именно заказчик во многом выступает «провокатором», разделяя ответственность между командами. Это само по себе неплохо, и, если бы не общепринятое разделение команд и обязанностей между ними, это был бы управляемый конфликт.

Но мы уже знаем, что обе службы не самодостаточны. Они разделены «служебной» баррикадой и при этом должны не только взаимодействовать между собой на поле передачи ответственности сообразно стадиям жизни продукта, но и активно участвовать в решении проблем друг друга.

Другой аспект влияния заказчика — его стратегия и методология развития бизнеса. В данном случае я говорю о непонимании, как выглядит процесс разработки конкретного IT-решения. Не обладая таким пониманием, заказчик часто требует сделать из кота кита, а потом приделать ему крылья. И всегда всё срочно. Иногда это оправдано ситуацией и новаторством идеи, иногда это следствие гонки за лидером рынка и спешное копирование. Причины могут быть самые разные, но итог один.

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

Процессы разработки


Наконец-то мы почти добрались до того, ради чего всё затевалось. Что имеет ключевое значение для службы эксплуатации?

  1. Прозрачность выполненных доработок. Для управления изменениями необходимо понимать, что, как и зачем было сделано.
  2. Документация по логике работы и обслуживанию. В идеале — в виде инструкций. Залог соблюдения SLA — не только надежность, но и четкое понимание, что и как делать, которое должно присутствовать у всех исполнителей. «Устные знания» здесь не подходят — очень часто в эксплуатации люди работают сменами, и просто невозможно всех собрать и все объяснить. Да и память в стрессовой ситуации (а авария — это всегда стресс) может подвести.
  3. Внятная процедура передачи в поддержку новой версии с тестированием ее эксплуатационных характеристик и корректности работы функционала. По-простому — регресс и нагрузочное тестирование. Простая работоспособность нового функционала волнует эксплуатацию в наименьшей степени: команда разработки сама починит неудачный релиз по гарантии. А вот привнесенную ошибку в старом функционале эксплуатация должна если не устранить самостоятельно, то хотя бы обработать, иногда и доказать вину разработки.
  4. Возможность передать свои требования к работе нового проекта. Именно разработка закладывает важнейшие эксплуатационные характеристики. К примеру, если ПО не умеет работать в кластере — эксплуатация не сможет самостоятельно сделать его действительно надежным.

Что такое служба эксплуатации и почему для кого-то вообще важно, как работает команда разработки, мы разобрались. Перейдем к самому интересному — разберем различные методологии разработки и их влияние на службу эксплуатации.

Начнем с классики: модели Waterfall.

Waterfall




Waterfall ориентирован на доставку законченных и проработанных функциональностей. Релизная модель — циклическая. Цикл занимает от нескольких недель (крайне редко) до кварталов и полугодий. Практически всегда происходит последовательный сбор требований, их анализ, выработка архитектуры решения, оценка его длительности, планирование, полноценное регрессионное тестирование в конце.

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

Основные проблемы Waterfall для заказчика — это продолжительность итераций и долгая стабилизация после релиза. Иногда заказчик вынужден ждать по несколько месяцев, прежде чем в продуктиве появится функционал, на создание которого достаточно недели.

Если результат далек от ожидаемого, заказчику придется потерпеть до конца нового цикла, а то и двух. Регулярно на его месте оказывается и служба эксплуатации. А технический функционал чаще всего стоит последним в очереди.

Каждый большой релиз сопровождается ворохом ошибок, который устраняется в период стабилизации. Обычно он превращается в ад для всех сторон — разработка вынуждена заниматься эксплуатацией, эксплуатация принимает инциденты и всеми силами «впихивает» их разработке на гарантийное устранение, а заказчик, глядя на весь этот бардак и потерянные деньги, рвет на себе волосы.

Несмотря на всё это, с точки зрения эксплуатации, Waterfall — наиболее равномерный и предсказуемый методологический процесс, в который можно встроиться. В целом, ни продолжительность цикла, ни стабилизация эксплуатацию особенно не волнуют. Чем больше времени пройдет между релизами, тем дольше удастся спокойно поработать — а это всегда плюс. Кроме того, когда есть уверенность в том, что еще полгода ничего не поменяется, гораздо проще вписывать в процесс свои работы.

К сожалению, очень часто заказчики настроены против Waterfall и требуют ускорить разработку проекта. В угоду этому желанию рождаются более гибкие методологии.


Agile




Как вы поняли, Waterfall — это очень долго, формально и влечет за собой тонны документации, на которой все и всегда халтурят. А заказчик требует всего и сразу. Как ответ на эти проблемы программисты придумали Agile манифест:

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

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

? Сотрудничество с заказчиком важнее согласования условий контракта.
И снова да, важнее. Но как без согласования условий контракта мы поймем, что и как нужно сделать? Как еще преодолевать взаимное недопонимание, кроме как общаться и договариваться посредством четко прописанного документа? Конечно, контракт — тоже не панацея, но он гораздо надёжнее, чем метод из девяностых:

— Вася, ты меня понимаешь?
— Ну, типа да, брат.

? Готовность к изменениям важнее следования первоначальному плану.
А вот это верно только в одном случае: если первоначальный план — полное бревно и то, что собирались построить, оказалось никому не нужно. Даёшь энтерпрайз-архитектора в каждые руки!

Результат слепого следования этому манифесту — в энтерпрайз-архитектора вынужден превратиться сам бизнес-заказчик (но чаще всего от такого он превращается в тыкву). Мало того, что это не свойственный ему «функционал», так еще и в IT придется разобраться.

SCRUM




Scrum — это одна из первых попыток подогнать Waterfall под идеологию Agile манифеста.
Основные черты скрама:

  • Работа короткими спринтами. Состав спринта после его начала не редактируется;
  • Планирование путем помещения отдельных User Story в журнал пожеланий спринта. На владельце проекта — выбор из «журнала проекта»;
  • Интересы заказчика представляет владелец проекта (Product Owner);
  • Команда разработки состоит из специалистов разных профилей: программисты, разработчики, архитекторы, аналитики. Команда отвечает за результат как единое целое;
  • Документацию и переписку заменяем на ежедневные обсуждения проекта всей командой.

В теории, это достаточно здравый подход, и во многом он напоминает миниатюрную версию Waterfall. Проблемы начинают возникать на этапе реализации. К сожалению, SCRUM из-за более короткого цикла провоцирует разбивать целостную функцию на отдельные куски и доставку функции по частям еще на этапе планирования спринта.  Я молчу о том, что по этой причине всё может пойти наперекосяк уже во время «забега». Короткие спринты не оставляют времени на менеджерский запас и выкрутиться становится крайне сложно.

В результате постоянной переприоритезации фича в готовом виде может весьма нескоро попасть в продуктив. К тому же, на этапе написания UserStory крайне сложно оценивать влияние планируемого функционала на конечную систему, так как заранее неизвестно её состояние в тот момент, когда таки появится этот функционал.

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

Для нормальной работы эксплуатация должна:

  • Участвовать в SCRUM-встречах;
  • Постоянно быть в курсе рабочих ситуаций у разработки;
  • Знать планы разработки и статусы по релизам.

В противном случае, успеть с приёмкой или сделать замечания будет невозможно. Конечно же, следовать всем этим пунктам у эксплуатации получается крайне редко, а если и получается, то это ведет к эскалации конфликта. Даже product-owner во время SCRUM-встречи может недальновидно проигнорировать интересы поддержки.

Kanban




Следующий шаг в эволюции методологий разработки — это Kanban. И без того короткие циклы SCRUM тоже показались бизнесу слишком долгими. Заказчика можно понять: всегда хочется первым получить самую крутую фишку. Да и менять планы неэффективно, получается многовато «накладных расходов».
Так что, как говорят строители, проще «лепить по месту».

Kanban представляет из себя IT-реализацию японской методологии бережливого производства. Но есть нюанс: в Toyota с помощью Kanban машины собирают из заранее спроектированных частей, между тем как разработка — это в первую очередь проектирование. В программировании части-функции просто копируются, их не надо постоянно «производить».

Kanban обычно идет рука об руку с процессами CI/CD. Спринтов здесь уже нет, задачи доставляются непрерывно по мере готовности, существуют жесткие ограничения на размеры таких задач. Из-за этого сложный функционал в целостном виде не доставляется почти никогда, так как не укладывается в размер задачи.

В таких условиях документация на систему действительно устаревает раньше, чем пишется, и теряет всякий смысл, так как нельзя зафиксировать какое-то состояние производимой (именно производимой, а не разрабатываемой) системы, в котором она была бы верна.

Для эксплуатации это означает невозможность обеспечить SLA: документации нет, и никто не знает, как работает система и как она должна работать.

Предсказуемость и гарантия продолжительной работы является основой выполнения SLA.

Впрочем, при таком подходе и службы эксплуатации обычно нет, только команда разработки, периодически отвлекающаяся на ремонт и (иногда) на «технический долг». Но никто из-за этого не переживает, так как планы не срываются. Сложно сорвать то, чего нет.

Как это и закладывалось авторами оригинального процесса, Kanban идеален для операционной деятельности, в которой планирование заменено реакцией на раздражители. Например, так выглядит работа с инцидентами — что сломалось, то и починим. В большинстве случаев, по известной процедуре. Однако Kanban совершенно не подходит для разработки, так как слабо подразумевает конечный результат. Выбор этой методологии обречет вас на бесконечный процесс — «мы строили, строили и до сих пор строим». Не надо так!

DevOps




Конечно, DevOps — это не методология разработки как таковая, но я не могу не вставить свои 5 копеек и не рассказать про самую распространенную попытку решить конфликт эксплуатации и разработки.

В теории, DevOps — это набор практик, нацеленных на активное взаимодействие специалистов по разработке со специалистами по информационно-технологическому обслуживанию и взаимную интеграцию их рабочих процессов друг в друга.

Базируется DevOps на идее тесной взаимозависимости разработки и эксплуатации программного обеспечения и нацелен на то, чтобы помогать организациям быстрее создавать и обновлять программные продукты и услуги. Снова про быстрое создание и обновление. Но для эксплуатации этих проблем вообще не существует.

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

На практике я чаще всего встречаю две реализации:

  • Команда админов эксплуатации сохраняется и занимается продуктивом.

В команде разработки появляются админы-автоматизаторы, решающие проблемы разработчиков вместо команды эксплуатации. Думаю, очевидно, что в итоге их решения, на скорую руку примененные в тестовых средах, в продуктив пускать не хочется, и конфликт только возрастает.

  • То же самое, но команда эксплуатации упраздняется в духе принципа «нет человека — нет проблемы».

Задачи управления доступностью сервиса уходят на второй план. Мотивированных на их решение людей вообще не остаётся. Периодически появляется команда DevOps-инженеров, но это ничего не меняет, так как приоритет их руководства — сроки выхода в релиз. Все прочие задачи можно задвинуть, пока никто не видит.

Если даже вернуться к исходной идее, что DevOps — это, скорее, про тестирование, и он должен гарантировать оперативный перенос гарантированно качественных изменений, то снова окажется, что исключать из процесса или заменять эксплуатацию нельзя. Фокус самой идеи именно в обеспечении качества процесса изменений и гарантии качества этих изменений. Заметьте, нигде не говорится про соблюдение SLA и управление доступностью. Да и высокое качество изменений (компонент) вообще не гарантирует высокую эффективность работы системы в целом.

Все предусмотреть и всё проверить невозможно — тестирование не гарантирует отсутствие аварий. Оборудование может износиться, система может выйти из строя в ходе эксплуатации в неожиданных условиях. Наконец, есть человеческий фактор.
Поэтому даже с командой DevOps без процесса эксплуатации не обойтись, и, как ни крути, документация понадобится. Когда что-то сломается, придется разбираться, как  оно вообще работало.

Вместо вывода


Так что же делать и как быть?

Бизнесу: разрабатывать внятную стратегию развития своего продукта и управлять конъюнктурой рынка, а не спешно реагировать на изменения.
Разработке: не превращать заказчика в энтерпрайз-архитектора. Построение инженерных или ИТ-систем — не его профиль, он специалист в какой-то локальной области бизнеса.
Всем вместе: попытки избавиться от службы эксплуатации вполне могут оказаться успешными, но вряд ли вы сможете отказаться от самого процесса эксплуатации, доступность должна оставаться под контролем. Либо этим будут управлять выделенные профессионалы, либо это будет дополнительной нагрузкой для разработчиков, решать вам.

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

Наверняка все вы так или иначе участвовали в описанных выше ситуациях и процессах. Поделитесь своим опытом в комментариях!

Комментарии (13)


  1. Taliesien
    01.11.2018 10:32

    Для определения причин конфликтов, самое главное это понимание: никто не хочет напрягаться. А всё новое — это причина напрячься.
    Если сотрудники принимают участие в сложном запутанном процессе, но им понятен, при внесении правок в этот процесс, даже если они упрощают его, они будут сопротивляться, и от степени их сопротивления, зависит степень конфликта. С другой стороны если пользователи сами предлагают какое-то изменение, они его понимают и им не надо напрягаться. Но в этом случае придется напрягаться разработчику, чтобы понять его. И он предлагает схемы более понятные ему. Пользователю надо напрячься, чтобы понять что ему предлагают, а он этого не хочет и получаем конфликт.
    Я конечно утрирую и упрощаю, но я по своему опыту могу сказать, что с любой стороны баррикады, на любом уровне управления, никто не хочет напрягаться и это является первопричиной конфронтаций.
    Разрабу нужен софт чтобы упростить работу. Он посмотрел кучу гайдов по нему. Он ему стал понятен. Он просит админа установить. А админ об этом никогда не слышал. Надо напрячься чтобы узнать как его развернуть. Он материт разраба.
    Сотруднику тех поддержки стали прилетать новые проблемы, с которыми он не сталкивался, он винит разрабов в криворукости, потому что ему приходится напрягаться чтобы вникать в новое.
    Итак далее. Примеров можно кучу привести.


    1. Logrann Автор
      01.11.2018 11:15

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


  1. maches
    02.11.2018 07:02

    В списке не хватает SRE. Site Reliability Engineering — как раз про удаление барьера между экслпуатацией и разработкой.


    1. Logrann Автор
      02.11.2018 10:26

      Я умышленно не стал об этом писать — SRE это то, чего не хватает эксплуатации, а мы все-таки про влияние процессов разработки:-)


  1. ggo
    02.11.2018 10:16

    Что такое:

    разрабатывать внятную стратегию развития своего продукта и управлять конъюнктурой рынка

    ?

    зы
    Немного утомился от повторения фразы: DevOps (и прочие agile'ы) не про ИТ, DevOps про бизнес.
    Бизнесу важно, чтобы нашелся бы человек, который бы сказал, я беру на себя ответственность за работу вот этого (ИТ) сервиса, от начала до конца (проектирование-разработка-внедрение-эксплуатация), и все возникающие при этом вопросы я буду решать здраво, эффективно, с достижением нужного качества. Очевидно, один в поле не воин, и чтобы достичь нужной цели (работа сервиса, который создает нужную ценность, с заданными свойствами) такой человек начинает строить команду, в которой у всех, опять же, одна цель (упомянута чуть ранее). И когда админ понимает, что никому не нужн стабильный сервис, который не создает нужной ценности. И когда разраб понимает, что никому не нужен сервис с новыми классными фичами, но который не работает. Вот тогда и появляется DevOps. (да, DevOps не про pipeline'ы, тесты, контейнеры, rest, и прочее)


    1. Logrann Автор
      02.11.2018 10:25

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


      P.S. То, что Вы описываете — это и есть функционал энтерпрайз-архитектора. И да, делать надо именно так, о чем я писал выше:-)


      1. ggo
        02.11.2018 11:39

        Развивать продукт по плану — этом мечта любого бизнеса. ;)
        Некоторые бизнесы довольно неплохо прогнозируются (например, предположу что реновация Москвы детально спланирована на несколько лет вперед).
        Что делать тогда, когда планы устаревают раньше завершения их планирования? (например, вы крупный банк, и решили запилить мобильное приложения для мелких предпринимателей. что реально болит у мелких предпринимателей — вы можете только предполагать, т.к. ни вы, ни ваши коллеги из банка мелкими предпринимателями не были)


        1. Logrann Автор
          02.11.2018 11:48

          Нужно провести исследование спроса, проанализировать результаты, конкурентные предложения. Это работа для системного аналитика и опять же энтерпрайз архитектора. Промах, конечно, будет в любом случае — но вот его масштаб и глубина последствий при правильно проведенной аналитической работе значительно мньше и не столь критичны, чем В случае тыкания пальцем в небо. А значит, можно будет не спешить с корректировкой и колличество итераций будет существенно меньше. Хороший план, опять же, всегда будет иметь запас на корректировки;-)


          1. ggo
            02.11.2018 20:05
            +1

            Я был неоднократным свидетелем того, как умные опытные люди долго и тщательно продумывали, планировали, запускали продукт, а после запуска выяснялось неожиданное, и в результате на ходу приходилось переобуваться (и то, потому что умные и опытные, в обратном случае продолжили бы копать по старому плану — «эффект ожидания автобуса» в действии). При этом абсолютное большинство сопричастных ИТ-ников думало: нуу тупые, не смогли очевидное предвидеть.
            И да, вдумчиво планировать, анализировать, опрашивать, изучать и прочее нужно. Но в некоторых областях, неопределенность остается даже при всех ухищрениях планирования.


            1. Logrann Автор
              03.11.2018 09:26

              Конечно неопределенность будет. Но от тщательности проработки идеи будет напрямую зависеть объем и срочность корректировок. Либо мы будем находиться в процессе постоянного переделывания, либо в процессе сделали, посмотрели, немного подправили. Переделываем только в особых случаях.


      1. ggo
        02.11.2018 20:26

        Еще раз прочитал абзац про DevOps.
        Там ни слова про общую цель.

        Увы, DevOps без общей цели не работает.
        У вас могут быть автодеплои, докеры, автомониторинги, автотесты, автоконфигурации и прочее, но не быть DevOpsа.
        И наоборот, быть DevOps, и отсутствовать автодеплои, докеры, мониторинги….
        И у вас наглядные примеры тому. Когда внедряют атрибуты DevOpsа, но не сам DevOps.
        Примерно такая же история со Скрамом. Проводим дейли митинги, ретро, ператаскиваем карточки и считаем что у нас Скрам. Тогда как Скрам вертится вокруг идеи самоконтроля, саморазвития на основе непрерывной обратной связи.


        1. Logrann Автор
          03.11.2018 09:36

          Ну я всё-таки не разработчик и смотрю со стороны на то, как это внедряют в реальной жизни. Есть там общая цель — прекрасный продукт. Беда именно в том, что эту цель трактуют по-разному. И DevOps, где в первую очередь оно Dev, трактуют её исходя из своей системы ценностей. А у Ops она принципиально другая, о чем я и писал. И подружить одно с другим на низком уровне не получится. Надо подниматься выше, на уровень управления продуктом в целом, и там принимать взвешенные решения исходя из стратегии развития, внимательно выслушивая обе стороны. Этим должен заниматься человек с техническим прошлым как минимум. Не видел еще ни одного бизнесс-заказчика, который бы понимал важность и последствия тех или иных технических решений. Т.е. управлять конфликтом, балансируя интересы сторон на благо продукта и объясняя почему было решено именно так.


  1. mskotyn
    04.11.2018 14:10

    Цинично отмечу, что «служба эксплуатации» это не первая, а вторая производная от бизнеса. Первая производная — это «служба разработки». «Служба эксплуатации» создается чтобы сэкономить на девелоперах — за счет найма более дешевых опсов, которые возьмут на себя часть работы девелоперов по поддерке продукта.
    Даже когда покупается готовое решение — все равно его кто-то разработал и при этом уже произвел подготовку к передаче в эксплуатацию (что включается в цену). Когда разработка ведется в рамках компании — издержки на передачу в эксплуатацию теоретически должны снижаться, но при возникновении разногласий между разработкой и эксплуатацией — они могут даже увеличится. А дальше бизнес смотрит просто — где меньше затраты — когда девелоперы занимают поддержкой или когда девелоперы передают продукт выделенному отделу эксплуатации.

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