Иван работал в большой организации в отделе, связанном с 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 для метрик – они позволяют легко подгрузить и объединить данные, а также построить все необходимые графики.
Иван взял «быстрые результаты» на вооружение и в следующих проектах всегда старался сначала сделать минимально работающую систему, дающую полезность, а уже потом браться за остальное. И это всегда работало.
Если история Ивана показалась Вам полезной, буду этому чрезвычайно ��ад.
Напишите, пожалуйста, в комментариях Ваш случай, когда быстрые результаты дали эффект.
