Иван работал в большой организации в отделе, связанном с DevOps. Ежедневно тысячи сотрудников пользовались инструментами DevOps для создания, проверки и внедрения своего программного обеспечения.
Тысячи дистрибутивов в день, прошедших через конвейер, было нормальной ситуацией.
Однако, где большая сила – там и большая ответственность. Неизбежные трудности команд выливались в сотни обращений в техническую поддержку в день.
Естественно, многим не нравились инструменты DevOps. Кто-то говорил, что они слишком глючные, а другие считали, что можно обойтись совсем без них, и это будет гораздо быстрее.
Руководство компании понимало, что все 100% команд не могут быть довольны DevOps-ом, однако точных данных не было. Хорошо было бы увидеть наличие проблем на конвейере, однако не было известно даже обычное количество дистрибутивов, проходящих через него в день. Что уж тут говорить о серьезных метриках.
Вопрос о метриках DevOps поднимался постоянно — они были всем очень нужны.
Иван, как сотрудник, разбирающийся в метриках и хорошо знающий технологию DevOps, плотно участвовал в подготовке проекта.
Вместе с DevOps-админами он проработал возможную архитектуру решения, а также проштудировал огромное количество литературы, посвященной DevOps-метрикам. Не осталось ни одной статьи в Интернет и ни одной книги по этой теме, которой бы он не прочитал.
В результате родилось полноценное техническое решения, которое Иван представил руководству.
Реакция руководства была неожиданной – решения о реализации принято не было.
«Это фиаско, братан» — сказал с усмешкой добрый коллега, выходя вместе с Иваном с совещания.
Несмотря на иронию, он был прав. Если решение не принято, значит был какой-то сдерживающий фактор, который Иван не увидел и не учёл.
Руководство убедилось в технической возможности реализации DevOps-метрик, но всё равно сомневалось.
И вызвано это было очень простой причиной: техническое решение показало, что реализация хотя и возможна, но потребует большого количества человеческих и технических ресурсов, т.е. будет дорогой. А вот будет ли от этого какой-то реальный полезный результат – большой вопрос.
Когда речь идёт о дорогом проекте, то:
В общем, старт проекта откладывался на неопределенное время. Задача казалась Ивану совершенно нерешаемой.
Всё решил случай. Однажды на почту пришло письмо о том, что в отдел взяли двоих студентов на стажировку. Один из студентов готов был взяться за какую-нибудь небольшую работу.
Иван подумал, что может быть получится сделать по метрикам хоть что – и отправил студенту техническое задание на урезанный до невозможности кусочек проекта.
Всё, что там было – это вытаскивание данных из Jenkins и Nexus самым простым из всех возможных способов.
Каково же было удивление Ивана, когда всего через пару дней студент пригласил его посмотреть на работающую систему. На вопрос «Чем я заслужил такой высокий приоритет?» последовал ответ: «У тебя единственного было нормальное ТЗ».
Как бы то ни было, но система заработала. Она вытаскивала данные из Jenkins и Nexus и складывала в собственную БД.
Иван понял, что нужно доделать оставшуюся часть как можно быстрее. Он использовал бесплатную версию QlikView, чтобы сформировать отчёты из сырых данных и уже к вечеру первый вариант метрик DevOps был готов.
Следующий понедельник был прорывом. Увидев работающие метрики, руководитель Ивана воскликнул: «Это самые полезные данные, которые я видел за последнее время!»
Вопрос с ресурсами был решен мгновенно, и уже в ближайшие несколько дней проект с метриками запустился на полную катушку.
Иван поступил грамотно и сам того не осознавая выдал «быстрые результаты» — работающую систему с максимально урезанным функционалом, дающую реальную пользу.
«Быстрые результаты» работают, ведь когда речь идёт о большой дорогой системе, неизбежно возникает много неясностей. При существенной дороговизне результат не всегда очевиден.
Поэтому старт работ постоянно откладывается или от системы отказываются совсем.
Быстрые результаты помогают проверить гипотезу минимальными средствами. Главное – постараться сделать прототип без привлечения дополнительных ресурсов и так, чтобы он при этом нёс ценность и пользу.
Несколько инсайтов, полученных Иваном из проекта:
Иван точно знал какие именно метрики ему понадобятся, вплоть до макетов экранов. Это позволило ему быстро откинуть лишний функционал и оставить только то, без чего метрики полностью теряли смысл.
Из десяти предполагаемых к реализации DevOps-метрик Иван оставил только одну, причем ограничив её одним стендом и одной командой. По сути, это являлось максимально концентрированной выжимкой с одной стороны, и практическими реальными данными – с другой.
Такой урезанный вариант позволил решить одну совершенно практическую задачу – проанализировать реальную команду и понять, дадут ли по ней метрики тот результат, который от них ожидали.
Простейшая схема Deployment с информационными потоками и данными очень хорошо помогла Ивану понять где что лежит и как проще это достать.
Jenkins: джобы. Что в джобах требуется для метрик? Как это вытащить? Какими протоколами, с каких адресов?
Nexus: дистрибутивы. Чтоб из Nexus требуется для метрик? Чем это достать?
Справочные системы: отбросить, т.к. для метрик они не нужны.
Как объединить данные? Где это сделать легче всего, чтобы реализовать как можно быстрее?
Если можно обойтись готовой выгрузкой в XLS или CSV – лучше сделать это и не кодировать вовсе.
Иногда без кодирования не обойтись, но всё равно надо выбирать самый лёгкий вариант.
Например, Jenkins отдаёт данные в RSS и JSON. Выбирайте тот вариант, который легче реализовать.
Nexus возвращает только XML? Ну что же, тут ничего не поделаешь, придётся кодировать.
Супер-автоматизация для быстрых результатов не нужна. Можно обойтись кодами команд вместо их названий. Не стоит подключать дополнительные системы только ради обогащения данных. Это всего лишь цветочки и наведение красоты – лучше сделать без них и сэкономить время.
Вместо записи в БД можно записать в обычный текстовый файл или csv, если так будет быстрее.
Где можно запустить вручную – запускайте, не тратьте время на шедулер.
Если проще написать на лёгком скриптовом языке типа Python или PHP – пишите. Всё равно Вы делаете по минимуму, поэтому переписывать много не придётся.
Используйте инструменты, позволяющие получить результат быстро, например, бесплатный QlikView или Tablue для метрик – они позволяют легко подгрузить и объединить данные, а также построить все необходимые графики.
Иван взял «быстрые результаты» на вооружение и в следующих проектах всегда старался сначала сделать минимально работающую систему, дающую полезность, а уже потом браться за остальное. И это всегда работало.
Если история Ивана показалась Вам полезной, буду этому чрезвычайно рад.
Напишите, пожалуйста, в комментариях Ваш случай, когда быстрые результаты дали эффект.
Тысячи дистрибутивов в день, прошедших через конвейер, было нормальной ситуацией.
Однако, где большая сила – там и большая ответственность. Неизбежные трудности команд выливались в сотни обращений в техническую поддержку в день.
Естественно, многим не нравились инструменты DevOps. Кто-то говорил, что они слишком глючные, а другие считали, что можно обойтись совсем без них, и это будет гораздо быстрее.
Руководство компании понимало, что все 100% команд не могут быть довольны DevOps-ом, однако точных данных не было. Хорошо было бы увидеть наличие проблем на конвейере, однако не было известно даже обычное количество дистрибутивов, проходящих через него в день. Что уж тут говорить о серьезных метриках.
Вопрос о метриках DevOps поднимался постоянно — они были всем очень нужны.
Иван, как сотрудник, разбирающийся в метриках и хорошо знающий технологию DevOps, плотно участвовал в подготовке проекта.
Вместе с DevOps-админами он проработал возможную архитектуру решения, а также проштудировал огромное количество литературы, посвященной DevOps-метрикам. Не осталось ни одной статьи в Интернет и ни одной книги по этой теме, которой бы он не прочитал.
В результате родилось полноценное техническое решения, которое Иван представил руководству.
Всё пропало
Реакция руководства была неожиданной – решения о реализации принято не было.
«Это фиаско, братан» — сказал с усмешкой добрый коллега, выходя вместе с Иваном с совещания.
Несмотря на иронию, он был прав. Если решение не принято, значит был какой-то сдерживающий фактор, который Иван не увидел и не учёл.
Руководство убедилось в технической возможности реализации DevOps-метрик, но всё равно сомневалось.
И вызвано это было очень простой причиной: техническое решение показало, что реализация хотя и возможна, но потребует большого количества человеческих и технических ресурсов, т.е. будет дорогой. А вот будет ли от этого какой-то реальный полезный результат – большой вопрос.
Когда речь идёт о дорогом проекте, то:
- Презентации не производят впечатления,
- Макеты экранов не производят впечатления,
- Примеры не производят впечатления.
В общем, старт проекта откладывался на неопределенное время. Задача казалась Ивану совершенно нерешаемой.
Судьбоносный случай
Всё решил случай. Однажды на почту пришло письмо о том, что в отдел взяли двоих студентов на стажировку. Один из студентов готов был взяться за какую-нибудь небольшую работу.
Иван подумал, что может быть получится сделать по метрикам хоть что – и отправил студенту техническое задание на урезанный до невозможности кусочек проекта.
Всё, что там было – это вытаскивание данных из Jenkins и Nexus самым простым из всех возможных способов.
Каково же было удивление Ивана, когда всего через пару дней студент пригласил его посмотреть на работающую систему. На вопрос «Чем я заслужил такой высокий приоритет?» последовал ответ: «У тебя единственного было нормальное ТЗ».
Как бы то ни было, но система заработала. Она вытаскивала данные из Jenkins и Nexus и складывала в собственную БД.
Иван понял, что нужно доделать оставшуюся часть как можно быстрее. Он использовал бесплатную версию QlikView, чтобы сформировать отчёты из сырых данных и уже к вечеру первый вариант метрик DevOps был готов.
Следующий понедельник был прорывом. Увидев работающие метрики, руководитель Ивана воскликнул: «Это самые полезные данные, которые я видел за последнее время!»
Вопрос с ресурсами был решен мгновенно, и уже в ближайшие несколько дней проект с метриками запустился на полную катушку.
Иван поступил грамотно и сам того не осознавая выдал «быстрые результаты» — работающую систему с максимально урезанным функционалом, дающую реальную пользу.
«Быстрые результаты» работают, ведь когда речь идёт о большой дорогой системе, неизбежно возникает много неясностей. При существенной дороговизне результат не всегда очевиден.
Поэтому старт работ постоянно откладывается или от системы отказываются совсем.
Быстрые результаты помогают проверить гипотезу минимальными средствами. Главное – постараться сделать прототип без привлечения дополнительных ресурсов и так, чтобы он при этом нёс ценность и пользу.
Несколько инсайтов, полученных Иваном из проекта:
Сначала представьте какой конечный результат Вам нужен
Иван точно знал какие именно метрики ему понадобятся, вплоть до макетов экранов. Это позволило ему быстро откинуть лишний функционал и оставить только то, без чего метрики полностью теряли смысл.
Из десяти предполагаемых к реализации DevOps-метрик Иван оставил только одну, причем ограничив её одним стендом и одной командой. По сути, это являлось максимально концентрированной выжимкой с одной стороны, и практическими реальными данными – с другой.
Такой урезанный вариант позволил решить одну совершенно практическую задачу – проанализировать реальную команду и понять, дадут ли по ней метрики тот результат, который от них ожидали.
Простая диаграмма с архитектурой сильно упрощает дело
Простейшая схема Deployment с информационными потоками и данными очень хорошо помогла Ивану понять где что лежит и как проще это достать.
Jenkins: джобы. Что в джобах требуется для метрик? Как это вытащить? Какими протоколами, с каких адресов?
Nexus: дистрибутивы. Чтоб из Nexus требуется для метрик? Чем это достать?
Справочные системы: отбросить, т.к. для метрик они не нужны.
Как объединить данные? Где это сделать легче всего, чтобы реализовать как можно быстрее?
При возможности обойдитесь без кодирования. Совсем
Если можно обойтись готовой выгрузкой в XLS или CSV – лучше сделать это и не кодировать вовсе.
Иногда без кодирования не обойтись, но всё равно надо выбирать самый лёгкий вариант.
Например, Jenkins отдаёт данные в RSS и JSON. Выбирайте тот вариант, который легче реализовать.
Nexus возвращает только XML? Ну что же, тут ничего не поделаешь, придётся кодировать.
Не навешивайте лишнего. Уберите всё
Супер-автоматизация для быстрых результатов не нужна. Можно обойтись кодами команд вместо их названий. Не стоит подключать дополнительные системы только ради обогащения данных. Это всего лишь цветочки и наведение красоты – лучше сделать без них и сэкономить время.
Вместо записи в БД можно записать в обычный текстовый файл или csv, если так будет быстрее.
Где можно запустить вручную – запускайте, не тратьте время на шедулер.
Если проще написать на лёгком скриптовом языке типа Python или PHP – пишите. Всё равно Вы делаете по минимуму, поэтому переписывать много не придётся.
Используйте инструменты, позволяющие получить результат быстро, например, бесплатный QlikView или Tablue для метрик – они позволяют легко подгрузить и объединить данные, а также построить все необходимые графики.
Иван взял «быстрые результаты» на вооружение и в следующих проектах всегда старался сначала сделать минимально работающую систему, дающую полезность, а уже потом браться за остальное. И это всегда работало.
Если история Ивана показалась Вам полезной, буду этому чрезвычайно рад.
Напишите, пожалуйста, в комментариях Ваш случай, когда быстрые результаты дали эффект.
