Хабрахабр

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

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

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

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

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

Первые шаги

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

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

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


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

В таком режиме я провел пару лет до ноября прошлого года и думал, что понимаю устройство экосистемы. Система мне подходила — я поддерживал опыт программирования на 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. Пока писал инструмент появился еще и первый черновой план по сети. Я очень не хотел тратить на это время, но не смог найти готовую альтернативу, а поиск адреса для выделения на новый ресурс отнимал много времени.

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

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

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

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

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

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

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

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

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

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

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

Бери всё, не отдавай ничего.

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

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

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

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

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

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

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

Простые во внедрении и настройке инструменты породили процесс, а его проще контролировать.

Проблемы

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

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

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

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

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

Отдельно о KPI

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я описал две ошибки в начале работ над проектом. Продублирую их ещё раз.

Предварительный анализ обязателен.

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

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

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

Сроки и порог вхождения.

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

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

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

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

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

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

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

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

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

Не усложняй.

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

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

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть