Основы 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++ пройдет сразу в трех городах — в Москве, Новосибирске и Санкт-Петербурге. Одновременно. Как это будет и как попасть — узнайте на отдельной промостранице события.
