company_banner

Основы DevOps. Вхождение в проект с нуля

    В ноябре 2018 года в ЛитРес создали отдел информационного обеспечения и пригласили руководить Андрея Юмашева. Последний год отдел помогает компании работать и развиваться и держит под контролем всю инфраструктуру. Но так было не всегда. Перед тем, как наладить работу, Андрей столкнулся с руинами: полуживой Nagios, условно живой Cacti и коматозный Puppet, мертвая Вики на 120 страниц, несвязные таблицы с задачами и списком железа, устаревшая архитектура, 340 бездействующих ядер, 2 Тбайта оперативной памяти и 17 Тбайт дискового пространства, которые почему-то не были записаны в инвентарных таблицах. Планы, которые не работают, сроки, которые срываются, рабочее окружение и инструменты, которых нет — все это ждало Андрея в новом проекте.



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


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

    Немного о ЛитРес. Это крупнейший в России поставщик электронных и аудиокниг, издательство и куча партнерских проектов. Это сотни тысяч строк Perl, несколько кластеров баз данных и хранилища. Это 2 ГБ исходящего трафика в секунду, сотни тысяч уникальных запросов в сутки, несколько стоек в разных дата-центрах и больше 100 серверов. В общем, это не просто магазин электронных книг.

    Первые шаги


    Раньше я уже работал в ЛитРес на сдельной основе. Компания практикует аутстафф-разработку с оформлением удаленных сотрудников в штат.

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

    Дальше начинается «лёгкий аукцион» — любой разработчик может взять задачу или поторговаться. Хорошо поработал — получаешь оплату. Вообще не поработал — не получаешь. В игровой форме люди заинтересованы выполнять задачи. Чтобы узнать больше об этой системе посмотрите выступление Дмитрия Грибова.


    Работа за грибы.

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

    Я ошибался


    Меня пригласили в компанию и сообщили, что мои услуги как Perl-разработчика не нужны, и предложили возглавить новый отдел. В ноябре 2018 я стал руководителем информационного отдела.

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

    Чистота — залог здоровья


    Порядок — прежде всего.

    За первый месяц удалось изыскать:

    • разрозненные Google Таблицы с текущими задачами и щепоткой полезной информации;
    • разрозненные документы: Word, тексты, обрывки старых Вики на 120 страниц;
    • полуживой старенький Nagios;
    • условно живой мониторинг Cacti;
    • очень старый Puppet с редкими признаками жизни.

    Все эти руины еще и собирали 400 метрик.


    Руины, которые нашел за первый месяц.

    Я немного повеселел, бегло всё почитал и подоткнул к процессам Trello. В него перенес текущие задачи коллег и принялся мечтать — писать план на квартал и год.

    Первая ошибка

    Никаких планов, пока не изучишь местность.
    План пылал жаром и здоровьем, но не учитывал реальность. Он был прекрасен и прост: внедрить мониторинг, анализ логов и перевести деплой на CI/CD. Где-то в конце было вяленькое «анализ слабых мест проекта». Классика первых шагов.

    Я забыл о главном. Моя первоочередная задача не внедрять инструменты ради внедрения инструментов, а обеспечивать жизнеспособность и стабильность сервиса в целом.

    Пока я писал план и терзал вопросами коллег, поступили первые проблемы. На одной из нод одного из кластеров баз закончилось место, а на другой ноде того же кластера закончился SSD в целом. Я срочно закупил новые диски побольше и наш отдел оперативно набирал опыт по замене этих дисков копированием системы с диска на диск. После замены дисков мы собирали кластер с нуля через SST. Кластер построен на Percona и Galera, и такие развлечения ему даром не проходят.

    Пока я путешествовал между дата-центрами, зародились первые ростки сомнений относительно плана.


    А-а-а-а!

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

    Параллельно появилась еще одна вводная. В ЛитРес есть аудиоверсии книг. Чтобы слушатель не перематывал запись каждый раз заново, у нас есть механизм, который отслеживает момент остановки. Во время следующего прослушивания аудиоверсия воспроизведется с нужного отрезка. Для этой задачи потребовалось найти около 500 ядер пошустрее, Тбайт оперативной памяти и прокрутить немного анализа на Java.

    Я начал брифовать Azure, Google, DigitalOcean и всё прочее, что предоставляли дроплетные решения. Напрашивается контейнеризация, почему бы ее бодро не внедрить? Тем более, что в «великом» плане об этом был отдельный пункт.

    В переписках и торгах прошёл месяц, задач в Trello всё прибавлялось, из которых я генерировал весомую часть, а результат не прогрессировал. Я задумался — туда ли я иду? До меня всё как-то работало и не собирается останавливаться, независимо от того, сколько пустой активности я проявляю. Я сел вдумчиво изучать ту инвентаризацию, что удалось собрать по крупицам. Затем поднялся и поехал во второй тур по дата-центрам.

    Второй спокойный визит в дата-центры расставил всё по местам. Когда я увидел это всё не в консоли, не в Excel, а живьем, осознание реальности изменилось радикально. Я понял, что занят вообще не тем, чем должен. Потому что сначала нужно понять, с чем я вообще работаю.
    Пока я не понимаю с чем работаю, все планы — пустая трата времени.
    Я изучал стойки, сопоставлял реальность со списками, делал правки и наткнулся на шасси (semi unit) на 20 лезвий. Из 20 работали только 4. Подёргал лезвия и понял, что никакие дроплеты для решения нам не нужны. Потому что я нашёл 340 бездействующих ядер, 2 Тбайта оперативной памяти и 17 Тбайт дискового пространства! Это старые бекенды, старые ноды кластеров, которые просто перестали использовать, а время подтёрло память об их существовании. Я раскатал по этим лезвиям Kubernetes и избавился от одной крупной задачи.

    Вывод по первой ошибке

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

    Параллельно я вывел три правила. Это следствия из первой ошибки.


    Три следствия.

    Второй план


    Из первого плана выкинул второстепенные задачи — анализ логов и внедрение CI/CD. В масштабе общей катастрофы эти мелочи не важны. ЛитРес работал годами и наработал собственные логики по работе с логами, обзавелся самописным демоном-раскатчиком. Я отодвинул на пятый план то, что работало и не требовало вмешательства.

    Второй план выглядел примерно так.

    Разобраться с мониторингом. В текущем виде он не отражал минимум трети проблем, хоть и работал.

    Описать общую логику работы всего ЛитРес. Названия серверов это отлично, но ключевые связки это критически важное знание: что, откуда, куда, зачем и почему. Предыдущая ошибка хорошо дала понять, что без этого никак.

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

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

    Адаптация гайдов под реальность. Большая часть инструкций устарела или была неполной.

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

    Вторая ошибка

    Не недооценивай.
    Любой срок, который приходит в голову — недооценен. Несомненно, вы можете быстро принести пользу на проекте. Но до максимальной отдачи умножьте планируемое время минимум в два раза. Особенно на сложном и высоконагруженном проекте, который стабильно растет в трафике больше, чем на 100% за год.

    Почему минимум в два раза? Если проект нестабилен и не исследован, будьте готовы к тому, что любая активность породит другие активности в соседних местах. Казалось бы, замена дисков — что проще? Процедура простая, пока не столкнешься с закупкой, затем с планированием времени на downtime конкретных нод, затем с обслуживание после замены диска. Эту простейшую операцию я оценил в неделю. В итоге она заняла две с половиной недели — даже с простой схемой закупки.

    Другой пример — закупка и установка нового оборудования. Покупай и втыкай, что сложного? На это я отвёл не больше месяца без учёта срока доставки. На деле, одно шасси из трёх до сих пор стоит напротив моего стола. Все потому, что оборудованию просто не хватило места — мы посчитали место в дырках между текущей инсталляцией. Когда мы приехали в один из дата-центров с намерением перетряхнуть стойку, внезапно осознали, что два сервера «неприкасаемы». Первый — это узел сети, и трогать его попросту небезопасно. Второй — это корзина на 16 дисков, выключать которую чревато ресинком кучи данных. Соломку не подстелили, анализ не провели, и хорошо, что смогли воткнуть два из трёх.

    Если кажется, что все будет просто — скоро у вас будут проблемы. Эта установка породила новый вопрос — если у нас так всё плохо с местом, то как мы будем расширяться? Небольшая задача сейчас породила гигантскую потом. В 2020 по плану переезд одного дата-центра в другой и расширение остальных по стойкам. Это означает миграцию внутри дата-центра между модулями. К миграции добавилась реструктуризация сети и ее перевод на 10G.
    Не стоит недооценивать сроки, порог вхождения и последствия.

    Базовые понятия


    Конечно же, суть ошибок уже описана в Вики как базовые понятия.

    Любой бюрократический процесс длится не меньше месяца. Это относится к закупкам, заключению новых условий с дата-центром или прочими подрядчиками — ко всему. Примите как факт.

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

    Пока нет четкого понимания внедрения любой план по внедрению чего-либо остается планом. Чем короче шаги — тем лучше.

    Например, для перехода с MySQL на ClickHouse широкий шаг выглядит так: «Засетапим какой-нибудь сервер, потом нарисуем тикет на переинтеграцию и полетим!». На деле подробное изучение вопроса привело к новым шагам: дополнительная закупка оборудования, например, процессоров и дисков, детальные тикеты на изменение логики трекера поведения пользователя, сохранение обратной интеграции, серверы очереди, и много других.
    Чем подробнее в плане описана схема — тем лучше. Написать широким мазком — гарантия 100% ошибиться в сроке.
    Любой план подвергайте максимальной критике и рассчитывайте на максимальный риск. Обязательно смотрите на план с точки зрения бизнеса — какой профит принесет каждый шаг.

    Нам пришлось проводить обязательные внедрения: мониторинг, Ansible, но мы не забывали о бизнес-составляющей.

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

    Лучший способ справиться с ситуацией, где плохо разбираешься в теме, — попросить помощи специалистов, а не Stack Overflow. Голосовой контакт решает проблему в разы быстрее, чем длинные переписки или чтение документации.

    Спустя полгода


    Несмотря на то, что корневые задачи, на которые я упирал на старте, всё ещё буксовали, благодаря исследованиям и исправлениям, на руках появилось кое-что хорошее.

    Самописный инструмент по инвентаризации сетей и адресов. Он регулярно простукивал все наши подсети и дополнительно сверял данные с конфигурацией BIND. Это позволило легко и быстро вводить в строй новые сервисы и понимать реальную загрузку сетевых пулов. Я очень не хотел тратить на это время, но не смог найти готовую альтернативу, а поиск адреса для выделения на новый ресурс отнимал много времени. Пока писал инструмент появился еще и первый черновой план по сети.

    Puppet — уже не такой убитый и запутанный. Я вооружился выводом из ошибки номер один и даже не пытался переезжать в Ansible, который для меня комфортнее.

    Более-менее подстроенный Nagios. Я переселил его из офиса в дата-центр и распределил по трем точкам. Это было гораздо быстрее и бюджетнее, чем внедрять Zabbix. Мы заткнули дырку с алертами, которые некорректны по времени и событиям, простой перенастройкой правил и внедрением дополнительных контрольных нод.

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

    Сильно разбухшая Вики. Она «растолстела» от комментариев и инструкций по работе с окружениями.

    Три шасси ХП, которые купили для будущей установки.

    Понимание пути на остаток 2019 года в более четком приближении.

    Переработанная экосистема по ведению работ отдела.

    Все эти полгода я работал практически один. Сотрудники, которые достались по наследству, были больше системными администраторами. Они не особо рвались вникать в суть DevOps.

    С большим трудом я нашел в команду двух специалистов — джуниора и мидла. Я собрал максимальное количество знаний, явок и паролей у текущих администраторов и с тяжелым сердцем с ними расстался.

    Рабочая система, окружение и инструменты


    Расскажу о важности внедрения рабочей экосистемы и окружения. Я уже упоминал о Trello, но не сказал почему и зачем внедрял. Никакая работа не будет строиться без постановки задач и структурированных данных. Об этом частично свидетельствует первая ошибка — собирай всё, что есть.
    Бери всё, не отдавай ничего.
    Процесс — двигатель прогресса. Поэтому всё это время я прорабатывал систему, несмотря на завал исследований и текучки. Благодаря системе, через полгода я поставил паровоз отдела на стабильные рельсы.

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

    Не усложняем инструменты, идем от простого и внедряем нужное. Ещё в начале года я думал, какой таск-трекер нам подойдет. Сразу отмел Jira и Redmine — слишком много контроля. Мы бы тратили время на заполнение формочек, а не на задачи. Google Таблицы — думаю, что не стоит объяснять, почему нет.

    Trello подходил идеально. Несколько простых колонок: «Backlog» — куда складываются все замеченные ошибки или задачи на будущее, «К выполнению» — основные задачи, которые надо сделать, и «Готово». Чуть позже колонок стало пять: «Backlog», «Пауза», «Спринт», «Готово» и «Изучение».

    В «Паузу» переносили вещи, которые потеряли актуальность в процессе спринта. В «Изучение» — задачи, которые требовали исследования и не должны были потеряться до момента осмысления и переноса знаний в Вики. «Спринт» стал свидетельством того, что мы перешли на спринт-систему. Мы поэкспериментировали и выбрали оптимальный тайминг — 2 недели. Этот отрезок мы используем и сейчас, но для вас подойдет другой. Для каждой компании время на спринт индивидуально.

    Обязательные еженедельные собрания — этоследующее нововведение, после Trello. Мы практически не работаем в офисе. Время, что могли бы тратить на дорогу, мы посвящаем работе. Но раз в неделю весь отдел собирается в офисе на 2-3 часа с перерывами, и обсуждает ход спринта и возникшие задачи. Соответственно, дополнительно раз в две недели мы планируем следующий спринт.

    Затем пошли внедрения минимально необходимых инструментов. Все служебные репозитории с конфигурациями — Puppet, Nagios, DNS — вынесли из SVN в свежый GitLab. К нему прицепили Jenkins. Теперь обновление конфигураций DNS шло в автоматическом режиме, а правки коллег по Puppet можно было вычитывать через мерж-реквесты проще и удобнее. Раньше пароли передавали от человека к человеку, теперь аккуратно собрали в 1Password. Сейчас это единственное платное решение в инфраструктуре.
    Простые во внедрении и настройке инструменты породили процесс, а его проще контролировать.

    Проблемы


    В ЛитРес рос трафик и добавлял работы: сбоящие кластеры, вышедшие из строя железки, комплектующие. Приближалась вторая половина года, на которую было запланирована разработка масштабирования.

    В это время вышло два бестселлера — новая книга популярного автора и указ президента дружественной страны о блокировке ЛитРес. Массово посыпались жалобы о недоступности сайта. Указ был издан давно, но узнали мы о нём, только когда нас начали реально блокировать по всему широкому пулу адресов. К счастью, в указе была речь только об одном доменном имени — «литрес.ру».

    Возросший трафик (все хотели бестселлер) через прокси-серверы мы приняли за DDoS-атаку и заплатили за это звонкой монетой. Помню, как мы оплачивали счета одной компании, которая обещала нам защиту от DDoS. Сразу после оплаты я переключил DNS на их адреса, а через 10 минут вспомнил о первой ошибке и судорожно отщёлкивал DNS обратно. Мусорного трафика там не было, а конский ценник за проходящий через них трафик — книг, аудио, обложек — был. Не буду говорить, во сколько нам обошлись 20 минут жизни на чужих адресах.

    В тот же вечер я позвонил в Cloudflare и рассказал о наших проблемах. Добрый русскоговорящий менеджер быстро понял все нюансы ситуации с блокировкой и сумасшедшими цифрами за Anti-DDoS и выставил крайне лояльный ценник. Мы подумали, прикинулись валенками и перевели на Cloudflare только конкретный заблокированный сегмент на конкретном доменном имени. К нему присоединили большую часть мобильного трафика. Теперь мы отлично живём на их бесплатных адресах, а DDoS’ят нас крайне редко, то есть никогда.

    Перевод конкретного сегмента дал нам понимание состояния нашего кеширование. Мы сразу внесли обновления и получили хорошую пользу для KPI.

    Отдельно о KPI


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

    Проект лучше живёт с чётким KPI. В нашем случае — это три простые вещи.

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

    В нашем случае зарплата никак не зависит от KPI, а квартальная премия — очень. Поэтому, спустя несколько месяцев, когда пришли к KPI, мы переосмыслили все предыдущие планы с его учётом.

    Даже не так. Второй план был выполнен на 90%. Я погрузился в проект до ноздрей, чтобы было чем дышать. Коллеги — по пояс, как минимум. Нам предстояло понять куда двигаться дальше. Мы потушили много пожаров и научились работать с проблемами, поэтому сосредоточились на укреплении инфраструктуры и слабых местах.

    Волевым усилием отказались от некро-Nagios и некро-Puppet и начали переход на Zabbix с Grafana и Ansible. В плане это отразилось как «внедрение полноценного мониторинга и системы контроля конфигураций серверного окружения».

    Мы толком не работали с Prometheus и не хотели тратить время на его изучение с нуля, но знали Zabbix. Поэтому основной мониторинг перевесили на Zabbix, а на Prometheus — сбор метрик по базам данных. С места в карьер никто не бросался — новые инструменты аккуратно присоединили к старым. Мы и сейчас переносим некоторые данные в них по мере работы с той или иной активностью.

    Выделили слабые точки, которые сильно влияют на нас, когда прилетает больше трафика.

    • Количество бэкендов.
    • Скорость основного кластера базы данных.
    • Качество отдаваемого контента.
    • Сеть.

    Цветовая дифференциация


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

    Я слаб в сетях и рутинных работах. Однажды трактор перерубил интернет-канал в одном из дата-центров, когда что-то там копал. Я поручил проверить коллеге, переключился ли у нас узел. Он понимает в этом гораздо больше. Списки по регистраторам и доменам собирает другой мой сотрудник. У него все хорошо с рутинными действиями. Они не приводят его в состояние психоза.

    Благодаря выделению слабых мест, я провёл анализ текущего состояния отдела и внедрил цветовую дифференциацию по штанам.


    К началу года был я и 2 системных администратора. К концу 3 квартала отдел частично собран «с улицы», а частично — из существующих сотрудников. Он стал выглядеть так.

    Два джуна. На них рутинная и физическая работа: замена дисков, обслуживание оборудования под надзором старших коллег, работы по настройкам мониторинга, мелкие задачи по Ansible, сбор информации и документирование.

    Два мидла. Один мидл с уклоном в сеть для работы по сети, поиска подрядчиков на ее обслуживание и основных задач. Второй мидл с уклоном в менеджмент. Кроме основных задач он помогает с контролем спринта.

    Архитектор баз данных.

    Я — архитектура, административная работа, принятие решений. Капитан корабля под присмотром технического директора компании.

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

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

    Отдельно об ошибках


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

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

    На это все уйдет не меньше месяца. Минимум месяц до момента, пока не начнешь что-то понимать. У меня на базовое понимание ушло три месяца, а изучение всего, что есть, идет до сих пор.
    Сроки и порог вхождения.
    С этим сталкиваются все — менеджеры, разработчики, директора. Когда построил план и решил, что учёл первую ошибку, значит ты ее не учёл.



    Здесь так же, как с предварительным анализом — внедрение чего-либо не идет быстро. Особенно, если проект старый и монолитный.

    • Закладывайте на любую активность не меньше половины квартала.
    • Стройте большой план на год вперед, разбивайте его на кварталы.
    • Переводите работу на не слишком короткие, но и не слишком длинные спринты, чтобы корректировать собственную нагрузку.

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

    Бонусом упомяну третью ошибку, которую я почти не допускаю, но о которую многие спотыкаются.

    Третья ошибка — внедрение ради внедрения


    Воткнем Ansible? Отлично, а зачем, если текущий Puppet отлично работает? Вот когда он перестанет отвечать возросшим потребностям — тогда и начнем плавный переход.



    Приходите в проект и в первую очередь решаете внедрять CI/CD? Есть задачи важнее, честное слово. Без CI/CD проект выживет, а без анализа слабых мест — нет. Не генерируйте сущности просто так.

    Анализируйте саму суть работы, учитесь прогнозировать, а не держаться на гребне волны. С какой целью вы собираетесь что-то провести? Какой будет результат, какая польза для проекта и как отразится на общем KPI? Прежде всего закрывайте не техническую сторону проекта, а осознайте его бизнес-логику. Учитывайте бизнес-потребности — это то, что приносят прибыль проекту, а вам зарплату.
    Не усложняй.

    Причина рождает следствие:

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

    Следующая профессиональная конференция DevOpsConf состоится весной. Программа пока в разработке — подписывайтесь на рассылку, сообщим, когда определим даты и локацию. А ближайшая встреча DevOps-инженеров состоится на HighLoad++ 2019 в ноябре. В секции DevOps 13 докладов о нагрузках в AWS, системе мониторинга в Lamoda, конвейерах для поставки моделей, о жизни без Kubernetes, о жизни с Kubernetes, о минимализме Kubernetes и многом другом. Полный список тем и тезисов смотрите на отдельной странице «Доклады» и бронируйте билеты. В этом году HighLoad++ пройдет сразу в трех городах — в Москве, Новосибирске и Санкт-Петербурге. Одновременно. Как это будет и как попасть — узнайте на отдельной промостранице события.
    • +38
    • 21,1k
    • 8
    Конференции Олега Бунина (Онтико)
    345,30
    Конференции Олега Бунина
    Поделиться публикацией

    Похожие публикации

    Комментарии 8

      0

      Спасибо за статью, но это скорее не основы DevOps, а переезд ( или как сейчас модно говорить — трансформация ) в DevOps. В статье есть очень путные замечания при разгребании авгиевых конюшен, но очень мало технических подробностей. Для меня интересным был бы вопрос, как тех дир допустил такое в 2018 году, что нет мониторинга, инвентаризации и всей остальной централизации, чай ЛитРес не одностраничник с контактами компании ?

        0
        Это скорее не про DevOps, а как на технаря сваливаются обязанности проектного/процессного бюрократа. Но все честно, при такой смене работы так и происходит.
          0
          Я использую следующую методологию по определению сроков:
          1. Берем идеальную оценку — обычно она базируется на реальной (то есть базируясь на своем опыте) скорости реализации фичи/проекта для очень хорошо слаженной команды или вообще оценки «за сколько я бы один это сделал» в реалиях близких к идеальным. То есть когда прям «прет».
          2. Выбираем множитель — он расположен от Пи до Пи/2. Выбираем по кол-ву неопределенностей в проекте — если все новое, предм. область не ясна, требования не особо расписаны, технологии новые и т.д. — берите Пи. Если все более-менее ровно и уже делали подобное и команда хорошая и требования стабильны и качественны — Пи/2.
          3. Умножаем идеальную оценку на множитель — это и есть реалистичная оценка проекта.

          Из опыта — если проект начинает превышать множитель Пи от идеала — такой проект имеет вероятность «сходимости» вообще. То есть он скорее всего будет закрыт и в прод не пойдет
            0
            Покажите как выглядит куча сложных проектов в вашем Trello? Он же для этого слабо подходит.
              0
              Отличная статья, но я, простите, хотел бы побрюзжать. Как понимать фразу — некро-Nagios и некро-Puppet и начали переход на Zabbix? С учётом того что Заббикс родился на год раньше Нагиоса?
                0
                Мне кажется, что «некро» здесь означает не возраст, а состояние. В тексте было упоминание о
                «полуживой старенький Nagios» и «очень старый Puppet с редкими признаками жизни». Видимо, «некро» об этом)
                  +1
                  А точно, это все объясняет. Спасибо.
                    0
                    :)

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

              Самое читаемое