Хабрахабр

Джентльменский набор сисадмина

Админ — это тот человек, без которого ничего в ИТ-компании не заработает. А со счастливым и продуктивным админом, дело будет двигаться лучше и быстрее, поэтому комфортная рабочая атмосфера — забота компании. О том, с помощью каких инструментов сделать команду продуктивной, был доклад Антона Турецкиго (banuchka) на Highload++ 2017.

Но аспекты, мешающие качественной работе и способы их решения максимально универсальны и подходят практически для любой исполнительной команды. Антон любит инфраструктурные задачи и автоматизацию всего, что можно автоматизировать, поэтому его рассказ основан на примере настройки инфраструктуры в дата-центре и сопутствующих технологиях (Docker, Consul, Puppet...). Так что милости просим под кат за расшифровкой этого доклада.

Но это далеко не самое главное, для человека, который в Badoo работает, главное — это в первую очередь образ мышления и команда. Badoo с каждым годом растет, вот несколько чисел, которые это отражают: 350 млн сообщений в сутки, 364 млн зарегистрированных пользователей по всему миру, 300 тысяч новых пользователей в день. Badoo — это семья, это про людей и это круто!

Хочу начать с провокации, которую, возможно, кто-то не поддержит:

Админ — это главный человек в компании!

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

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

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

Многим в голову придет, что админ грустит от упавшего сервера и потерянных бэкапов. Давайте задумаемся о том, что заставляет админа печалится. Это все так, но, если бы админ каждый раз задумывался бы и уходил в печаль, когда он сделал что-то не так — а он каждый день делает что-то не так — нервов бы не хватило.

Поэтому я обозначаю проблему, которая заключается в некоем человеческом факторе, а именно в переключении контекста.

Переключение контекста

Есть достаточное большое количество исследований о том, что происходит, когда человека отрывают, и почему это плохо. Одно из последних хороших исследований — работа Криса Парнина, сотрудника технологического университета Джорджии. Он собрал кучу различных данных на эту тему и сделал достаточно много выводов, главный из которых звучит так:

Человеку, которого оторвали от работы над задачей, требуется 10–15 минут, чтобы вернуться к ней.

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

На практике вы, вероятно, сталкивались с такой ситуацией: приходишь на работу, провел весь рабочий день в запаре — весь день что-то делал, пообедать не успел, на мессенджеры и почту не ответил. Это теория — человек исследовал, пришел к выводам. Но в лучшем случае, к вечеру ты понимаешь, что не сделал и половины того, что планировал на рабочий день. К концу рабочего дня ты весь замученный, тебе кажется, что ты сделал очень много всего. Хуже, когда к тебе подходит менеджер или коллега и спрашивает: «А что ты сегодня вообще сделал?» и ты понимаешь, что бегал, бегал, бегал — а на выходе нет ничего.

Для админа — простого исполнителя — это так. Во многом это происходит от переключения нашего контекста и невозможности сконцентрироваться на задаче.

Фишка тимлидов заключается в том, что они, как маньяки, этот context-switching не то, что умеют переживать, но даже себе его иногда увеличивают, чтобы потом сократить. Но есть еще менеджеры/тимлиды и обратная сторона. Навык переключения бывает развит до того, что уходит всего 5 минут на погружение в новую задачу. То есть они сосредотачивают много встреч с этим переключением в несколько часов, а потом отдыхают вечером, работая над одной задачей. Но для админа и исполнителя лучше от переключений избавляться. Это очень круто, и за одно то, что они умеют это делать, менеджеров можно ценить и уважать.

Непрозрачность процессов

Второй важной проблемой является непрозрачность процессов, которую можно разделить на две зоны:

  1. непрозрачность процессов внутри команды;
  2. непрозрачность процессов вне команды.

Внутри команды — это то, на что мы можем повлиять: недоговорки или отсутствие согласования между участниками команды. Самое плохое, к чему вас может привести непрозрачность процессов внутри команды — это дублирование работы. В принципе, это неплохо, не считая того, что вы теряете, скорее всего, рабочее время одного из сотрудников.

Давайте возьмем его решение». Здесь можно найти плюсы и сказать: «Возможно, Вася сделал лучше, чем Петя! Это важно. Но они могли бы поговорить между собой, а делал бы кто-нибудь один.

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

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

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

Как решить проблему переключения контекста

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

Человек пришел свежий, все хорошо, он открыл свои рабочие инструменты, написал в чат и в почту, и тут телефон зазвонил — спрашивают, что ночью упало — отвлекся. Рассмотрим обычную ситуацию. Тут приходят друзья обсудить вчерашнюю футбольную встречу, зовут вечером попить пива или сейчас чаю. Дальше жена или девушка выложила клевую фотку — надо зайти полайкать, в Facebook тоже происходит движуха. И все это к человеку приходит со всех сторон понемножку.

У нас есть человек, есть его общая социальная жизнь, есть ее рабочий аспект. Что делать с данной проблемой? Мы не можем ему запретить ходить пить пиво после работы или пользоваться социалочками, потому что мы же не в тюрьме в конце концов. В данном случае мы можем рассматривать и оптимизировать только ту часть, которая касается его рабочих инструментов.

Поэтому мы решили посмотреть на то, какие рабочие инструменты есть у админа, откуда его часто дергают, и что мы можем сделать с тем, чтобы это уменьшить.

Работаешь над задачей, а тебе один написал, что ему важно это, другой — что ему важно то. Первая идея достаточно странная, но мы ее пробовали — это разрешить админу просто не пользоваться чатом, потому что в чат пишут много. И мы разрешили админам не использовать чат — не отвечать и ничего не писать там.

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

Это — не повышение по карьерной лестнице, просто ты довольно много знаешь о том, кто из твоих коллег в какой области хорош, ты знаешь общий поток задач и более-менее про приоритеты. Мы приняли отчасти странное решение — выделили одного члена команды и сказали ему: «Чувак, ты будешь условным лидером! Есть пул задач, которые сваливаются на всех админов в команде, ты видишь, кто чем занят, знаешь, какие сроки по задаче, и всегда можешь отдать ее человеку, который максимально быстро справится с ней; либо, если времени на выполнение много, можно поручить ее джуниору. Поэтому, давай, ты будешь работать по следующему сценарию. В принципе, идея вполне здравая. Джуниору необходимо рассказать базовые вещи, но ты знаешь, что, если ему помогут, он прокачается и все будет круто».

Мы можем делать таски, когда все горит и надо делать — мы не разбираемся, берем и делаем, неважно, кто. Одна из причин, почему она до конца не зашла, заключается в том, что у нас все админы любят работать над тем, что им нравится. Другое дело, когда у тебя есть выбор: «Я сейчас работаю над одной задачей и хочу настроить репликацию в MySQL, Puppet трогать не хочу — пусть кто-нибудь другой его делает».

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

Команде админов другие команды ставят задачи сделать что-то — забэкапить, восстановить и т.д. Приблизительно в тот же момент времени мы пытаемся догрузить Арбитра еще одной обязанностью. Когда, поставив задачу, он видит, что задача перешла в общем пуле со статуса «не назначено» на «назначено» на конкретного исполнителя, прошло 2-3 часа, один рабочий день, другой, а у задачи нет отбивок, не понятно, вообще занимаются его задачей или нет. Человек с такой заявкой — это, по сути, клиент, и он всегда ждет фидбэка.

Поэтому Арбитру теперь стало нужно устраивать one-to-one митинги с каждым членом своей команды, вести практически каждую задачу, спрашивать, есть ли по задаче трудности, чем можно помочь, и резюмировать собранную информацию раз в 1-2 дня. Есть админы, которые не очень любят вести свои задачи именно в виде переписки.

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

Матрица Эйзенхауэра

Суть заключается в том, что мы делим лист с задачами на 4 части по двум параметрам: Возможно, вы уже видели эту матрицу, просто не знаете названия.

  1. срочно / не срочно;
  2. важно / не важно.

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

Это отличный мотиватор для человека, когда твоя задача важна либо для команды, либо для проекта, либо просто для тебя. Стоит сразу заметить, что самая производительная и комфортная для исполнителя клеточка B — задача важная и не срочная. Плюс несрочности заключается в том, что ты предоставлен сам себе. Ты понимаешь, что работаешь не просто над какой-то ерундой, а над тем, чем люди будут пользоваться, и это добавляет стимула. У тебя есть время почитать, протестировать, произвести какие-то расчеты.

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

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

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

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

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

Люди просто вынырнули из пункта A, посмотрели по сторонам, а там есть пункт B — и мне комфортно, и всем хорошо — круто! Введя роль дневного дежурного и разделив задачи на совсем неважные и проектные, мы позволили всей остальной команде работать в самой комфортной зоне B над несрочными, но при этом важными задачами. Будем работать!

В нашем случае обычно работы в этом сегменте не происходит. Не оставлю без внимания задачи из пункта С. Звучит как-то бредово: «Срочно, но не важно» — либо срочно, либо не важно. Задачи с критериями «не важно, но срочно» либо становятся «не важно и не срочно», либо просто исчезают, и мы над ними не работаем.

Так как я коснулся того, что мы ввели роль дневного дежурного админа, давайте кратко пройдемся по тому, какие вообще админы у нас есть:

  1. Админ обыкновенный. В принципе, все занимаются всем всегда, но админ обыкновенный преимущественно работает над тасками в Jira.
  2. Дневной дежурный админ преимущественно отвечает на телефон и на эскалации от мониторинга.
  3. Ночной дежурный админ — некая смесь админа обыкновенного и дневного — ночью отвечает на звонки и эскалации, а днем работает как админ обыкновенный.

Как сделать процессы прозрачными

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

Это выглядит так:

  • Мы занимаем одну переговорку в Москве, одну в Лондоне.
  • Причем время установлено так, что в Лондоне только пришли на работу, а в Москве уже вернулись с обеда. Чтобы настроиться на рабочий всем надо порядка 40 мин. Поэтому мы в неформальной обстановке собираемся по телевизору, берем агенду и начинаем обсуждать.
  • Это обсуждение «многие ко многим». Мы рассказываем друг другу, какие важные проекты мы сделали, что ожидаем, что планируем делать, назначаем встречи друг другу.

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

Status Hero

Существует клевый инструмент, который называется Status Hero. Его суть в том, что, приходя на работу, ты планируешь сам для себя определенные задачи. В Status Hero есть 3 поля для заполнения. Причем это не обязательный инструмент, мы можем его не заполнять и им не пользоваться.

Я вписываю все это в план на сегодня. Фишка заключается в следующем: я пришел на работу свежий, и знаю, что сегодня хочу починить какие-нибудь DNS, настроить сброс метрик в Prometheus, посмотреть, как будут работать новые графики, и возможно, закрыть текущие задачи.

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

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

У нас есть специальная группа в HipChat, где после того, как кто-то заполнил форму, это показывается всей команде. В свою очередь команда это тоже видит. Если вдруг есть какой-то блокер, который он может разрешить и помочь тем самым своему коллеге, то он это делает. Человеку беглого взгляда достаточно, чтобы просмотреть чат и понять, что будут делать его коллеги. Это круто!

Почему Status Hero работает?

  1. Самый важный аспект заключается в том, что ты обещаешь себе. Из практике могу сказать, если ты обещаешь себе с понедельника до пятницы, то, скорее всего, к четвергу ты сделаешь хотя бы один из пунктов, который написал в понедельник. Status Hero каждый день тебе будет мозолить глаза и говорить: «Обещал — не сделал!» А еще и коллеги знают, которым ты фактически тоже пообещал, поэтому берешь и делаешь, просто через силу.

  2. Следующий положительный момент заключается в том, что полученная прозрачность дает возможность помогать друг другу. Когда я вижу, что, например, мой коллега собрался выполнить определенную задачу, в которой мои знания, возможно, больше, или я могу просто чем-то помочь, я говорю: «Давай, я тебе помогу. Я знаю, куда отправить документацию и что почитать, или сделай здесь сразу так, чтобы не потерять пару дней работы. Это будет лучше для тебя».

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

Status Hero вскрыл проблему

Но мало того, что Status Hero помог нам в организации этой деятельности, он еще вскрыл для нас одну достаточно странную проблему. Она заключалась в том, что на тот момент эксплуатационной документации либо не было вообще, либо ее было недостаточно.

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

Как только начали пользоваться Status Hero, статей во внутренней Wiki стало действительно больше, статьи стали править и комментировать, даже лайки ввели в Confluence, а также стали дополнять триггеры в системах мониторинга, которые срабатывают. Документация была, но в недостаточном количестве, как выяснилось. Мы стали писать более внятно, человеческим языком о том, что же там на самом деле происходит, кому позвонить и куда посмотреть.

Есть еще один аспект, в котором нам Status Hero тоже помогает. И это еще не все.

Team Contribution

Алексей Рыбак выступал на HighLoad++ срассказом про процесс Review в Badoo. Это крутая, преимущественно менеджерская штука, потому что им надо оценивать свои кадры: как мы работаем, как работает команда. С точки зрения менеджера это клевый инструмент, с помощью которого вся информация становится структурированной.

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

Это можно делать как в конце рабочего дня, так и в конце рабочей недели. Чтобы процесс написания Review не был таким больным, нам предлагается заполнять snippets.

В лучшем случае я напишу, что я делал в четверг и в пятницу, в худшем это будут 3 последних часа работы в пятницу. Но, так как мы уже говорили о проблеме переключения контекста, то, очевидно, не всегда возможно в пятницу, например, вспомнить, что я делал в понедельник или во вторник. Что касается daily snippets — рабочий день бывает разным, и вечером хочется пойти домой, в паб, — что угодно, но не заниматься писаниной того, что же я сделал за сегодня.

Мы писали в нем каждый день, что обещали сделать и что сделали. Здесь снова на помощь приходит Status Hero. За срок, который нам нужен, можно просто сделать выборку положительных моментов — того, что мы на самом деле сделали.

Тебе не нужно лезть в тикеты и вспоминать, что же ты там делал, долго или не долго. Мало того, что эта выборка позитивная, есть еще один плюс: в Status Hero мы писали для себя, и когда мы делаем выборку для написания полугодового отчета, то читая то, что сам для себя написал, ты погружаешься в перспективе в контекст.

Это прекрасно и замечательно, но

«Теория без практики мертва, практика без теории — слепа»
А. Суворов

Один день из жизни админа

Чтобы мои утверждения, что Status Hero клевый, не были голословными, давайте посмотрим на один день из жизни админа в Badoo. Ситуация полувыдуманная, но вполне реальная.

Он отдохнул и знает, что у него в перспективе большой проект. Приходит человек на работу с утра, например, после выходных. Допустим, он решил настроить инфраструктуру в новом дата-центре. Первое, что ему нужно сделать, чтобы начать работать, это спланировать рабочий день.

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

Человек это написал и подумал о том, что для того, чтобы поднять новый дата-центр, ему необходимо настроить инфраструктуру для xCAT.

Слишком подробно про каждую из этих систем рассказывать времени не хватит, рассмотрим их вкратце. Тут присоединяются ребята, которые тем временем пришли на работу в Лондоне, и каждый из них добавляет, что еще нужно поставить Puppet поставь — без него не заведешь, Consul тоже нужен, и как же без Docker, а glpi, и так далее.

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

Его поставили в дата-центр, смонтировали в стойки. Первый основной инструмент менеджмента — железо, которое только приехало с завода. Админу нужно обновить прошивки, поставить ОС, собрать Raid, и машину переместить на то место, в котором она потом будет работать.

Там мы храним базу всех наших подсетей, dns адреса, динамические диапазоны и прочую информацию. Мы пользовались и продолжаем пользоваться продуктом под названием xCAT, который в себе содержит PXE сервер и dhcp сервер. Для нас это является базой серверов, но базой в формате сервер — имя — mac адрес — сетевые интерфейсы и постоянный IP непосредственно в том кластере, в котором он будет располагаться, если мы переносим сервер в кластер.

Если происходит какой-то Kernel Panic, то мы получаем слепок с монитора просто в текстовом виде и потом можем им воспользоваться. Немаловажно, что xCAT предоставляет возможность следить за тем, что происходит в консолях серверов. Если дата-центр будет маленький — условно 100 машин, то все поместится на одной менеджмент-ноде, мы не будем поднимать вторую. То есть xCAT работает в формате, менеджмент-ноды, которая знает все обо всем, но может снять часть своей нагрузки, передавая ее сервисной ноде, на которой в свою очередь мы и поднимаем сервер консолей. Поэтому на схеме xCAT SN находятся в квадратных скобках. Если дата-центр большой, серверов с консолями много, мы возьмем и просто горизонтально увеличим количество SN и подцепим их все к мастеру.

На самом деле, человек, которые поднимает ДЦ и настраивает xCAT, запускает один контейнер с менеджмент-нодой, вносит туда информацию о новых подсетях, которые будут в этом ДЦ, генерирует файл с dhcp и сообщает, если это необходимо, сетевым инженерам о том, что для этих подсетей dhcp helper будет находиться на новом контейнере.

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

Docker

Я был бы не я, если бы я не сказал здесь слово Docker — шапку пришлось бы снять в конечном итоге. Но рассказывать глубоко про Docker не буду, его инфраструктура для любого нашего дата-центра выглядит приблизительно так.

У этой схемы было несколько итераций, пока мы внедряли Docker и им пользовались, но на данный момент рабочая схема registry в Badoo находятся в таком виде, как показано выше. Суть Docker здесь не в нем самом, а в том, как устроены registry, потому что он нам необходим для того, чтобы стягивать оттуда уже дальнейшие контейнеры наших сервисов и служб. Все образы, все слои и все остальное мы храним в Ceph через Swift API.

HTTP ноды, которые являются Docker distribution сервисом, мы можем горизонтально масштабировать сколько угодно, единственное условие заключается в том, что нам всегда необходимо вести все docker-registry ноды к одному адресу кэширующего сервиса Redis и указывать соответственно один endpoint для Ceph. Для того, чтобы хранить кэш из нашего registry, мы используем Redis.

Дальше находятся наши целевые серверы, которые обращаются к registry с тем, чтобы сделать pull или push. Перед HTTP сервисом в качестве балансировщика стоит nginx, который терминирует SSL, делает basic Auth.

Consul

В современных реалиях в новом дата-центре обязательно понадобится Consul, который на данный момент используется, скорее, не как service discovery для всего Badoo, а как service discovery для инфраструктурной части.

Это обычно, как минимум 3 master-сервера и синхронизация со всеми имеющимися дата-центрами. Демонстрировать, как базово выглядит инсталляция Consul в любом из дата-центров, наверное, никакого смысла не имеет.

Зачем инфраструктуре, тем более нового дата-центра Consul?

Puppet

Давайте посмотрим на нашу замечательную инфраструктуру Puppet.

Суть Consul здесь заключается в том, что мы поднимаем инфраструктуру сверху вниз (если смотреть на слайд выше):

  • Для начала работы нужен PostgreSQL, который будет в свою очередь необходим для PuppetDB.
  • Поднимая PostgreSQL, мы регистрируем его в Consul. Поднимая PuppetDB, мы берем информацию из Consul о PostgreSQL, коннектимся к нему и передаем информацию о PuppetDB обратно в Consul.
  • Дальше мы поднимаем необходимое количество Puppet-server нод на Java. Информацию для них мы берем из Consul, информацию о них мы кладем в Consul.
  • Последним этапом мы поднимаем load balancing на nginx, который занимается SSL терминированием, обслуживает 3 порта:
    1. порт для непосредственно Puppet агентов;
    2. порт для Puppet DB;
    3. порт для статистики.

Все остальные клиенты ходят через load balancing.

GLPI

У нас есть такая штука, которая называется glpi, она необходима для любого дата-центра. Все довольно топорно и просто — это сервис для инвентаризации.

Он работает следующим образом:

  • На каждом сервере запускается простой FusionInventory Agent, которые собирает всю информацию по железу, софту, антивирусам, файловым системам — все зависит от настроек. Нам обычно интересны всякие «железные» показатели: какой памяти сколько, какие диски, контроллер, кэш и т.д.
  • Эту информация через определенный временной интервал (в нашем случае раз в сутки) отправляется на некий PHP endpoint, в котором происходит обработка и передача данных в glpi базу данных.

Еще одно преимущество использования GLPI и FusionInventory состоит в том, что мы можем инвентаризировать не только серверное оборудование, но и сетевое, для того чтобы получить информацию, какие есть порты и какая на них скорость, и самое главное — какой сервер с каким серийником, находясь в какой стойке, подключен в какой сетевой узел и в какие порты. Результатом всего этого действа становится веб страничка, на которой можно смотреть всю эту информацию.

Мы получили домик счастливых людей, которые продуктивно работают: один задачу обозначил, другие ему помогли, в общем и целом ознакомились, почитали — и подняли такую штуку. Мы рассмотрели 5 инструментов, которые были описаны в нашей Wiki, наш гипотетический админ посмотрел на них и запустил по каждому не более 3-5 контейнеров — инфраструктура готова.

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

Итак, что необходимо для исполнителей (мне кажется, не только для админа):

  • Уменьшать переключение контекста. Дайте человеку работать — если он технарь, пускай сидит и работает, не отрывайте!
  • Делать процессы прозрачными. Если вы срываете сроки и есть подозрение, что что-то не так приоритизацией задач, дайте команде информацию о том, почему конкретная задача важна. Человек должен видеть дальше своего монитора, и знать, что его участие в проекте важно. Тогда он будет работать иначе, он будет понимать срочность и полезность своей работы.
  • Писать хорошую документацию. Причем хорошо, если эта документация будет разделена на разные части. Она может быть подробной и глубокой, если ты хочешь ознакомиться и зарыться. Но при этом у вас должна быть выдержка про сервис или службу, которая помещается на одну страницу и содержит набор из 5-6 действий, которые необходимо сделать до эскалации. Более того, документацию важно всегда держать в актуальном состоянии.

Когда вы увеличиваете прозрачность работы в отделе, проблема обновления документации решается сама собой, потому что вы видите, какие итерации происходят, и у вас постоянно спрашивают: «Обнови, обнови, обнови».

References

Это ссылки на различные исследования на тему context-switching, как грамотно работать, как не отвлекаться и делать больше, а также ссылки на все продукты, про которые я рассказывал, которые являются базой и опорой любого из дата-центров Badoo.

  • Why developers hate being interrupted,
  • Programmer Interrupted,
  • Interrupts: just a minute never is,
  • A diary study of task switching and interruptions,
  • No task left behind?: examining the nature of fragmented work,
  • xCAT,
  • GLPI, FusionInventory,
  • Puppet,
  • Consul,
  • Status Hero.

На ней Антон расскажет об эволюции инструментов и сервисов на вооружении команды эксплуатации Badoo, Сибирская версия конференции для разработчиков высоконагруженных проектов Highload++ Siberia стартует уже в понедельник и займет 25 и 26 июня.

И еще 30 признанных экспертов и представителей лидеров индустрии представят свои наработки и поделятся опытом — смотрите программу.

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

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

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

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

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