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