Заместитель технического директора Mail.Ru Group Татьяна Бахаревская рассказывает о пути системного администратора, о плюсах работы сисадмином и особенностях эксплуатации в крупной компании. Татьяна отвечала и отвечает за работу сервисов двух крупнейших порталов России.
Ведущий программы — Павел Щербинин.
— Расскажи немного о себе.
Устроилась младшим системным администратором в небольшой стартап, который разрабатывал свою поисковую систему и ряд других интернет—проектов. — Я пришла в профессию довольно давно. Выросла до серьезного системного администратора, потом возглавила отдел системного администрирования. Это был «Яндекс», где я проработала очень много лет. Мы научились нанимать, растить инженеров, сделали такие мероприятия, как Root, КИТ. В 2005 году в этом отделе работало 5 человек, а через 10 лет — 250, это была большая структура, образовалось несколько подразделений. Ru Group. В Яндексе я отвечала за непрерывную бесперебойную работу компании, а теперь уже скоро год как занимаюсь тем же самым в Mail. Поначалу казалось, что задачи похожие, но при ближайшем рассмотрении выяснилось, что общего много, но и различий хватает, и это интересно.
Это и просто эксплуатация, и системный администратор, SRE, SE, DevOps. — Есть много разных терминов для службы эксплуатации. Или это одно и то же? Расскажи про каждый подробнее. Чем они отличаются?
В какой-то момент это всё же разделилось на разные направления. — На самом деле, системный администратор — это довольно широкое понятие, начиная с того, что человек может отвечать за какой-то небольшой офис с небольшой офисной инфраструктурой на несколько сотрудников, заканчивая ответственностью за непрерывную работу высоконагруженного сервиса. Ru Group, «Яндекс», Google, системный администратор ближе к тому, что сейчас называется модными словами SRE — Site Reliability Engineer, то есть человек, отвечающий за доступность сайта. В таких компаниях, как Mail.
Про технологии надо понимать, как их применять, чем они отличаются. Наша работа требует много разных знаний о технологиях: Linux/Unix, сети, базы данных, веб-сервера, облачные технологии, состав оборудования, которое мы применяем для построения сервисов (процессоры, память, диски) и много еще чего. Писать код тоже надо. Всегда есть очень много рутинной работы, которую надо автоматизировать. На текущий момент основной язык для автоматизации — Python, плюс, конечно же, bash. Современные системные администраторы/SRE по большей части программируют. К примеру, самая лучшая документация по Linux: открыть код ядра и посмотреть, как всё устроено. Знание C тоже всегда было плюсом.
Про это уже довольно много рассказано на конференциях и написано в интернете. Еще важно понимать, как строить высоконагруженные и отказоустойчивые системы.
Итого, если подвести итог, современному инженеру, отвечающему за высоконагруженный сервис, надо уметь программировать, знать и применять различные технологии, иметь представление о том, как строить надежные и масштабируемые сервисы.
Очень интересен самый начальный этап. — Давай вернемся немного в прошлое. Почему ты выбрала эксплуатацию?
В те годы все приличные девочки хотели стать бухгалтерами. — Это было забавно. Там сказали, чтобы стать бухгалтером, нужно освоить счеты и арифмометр «Феликс», я решила, что это слишком сложно, и «знание компьютера» (так писали в объявлениях о работе) облегчит мне жизнь и поиск работы. Я тоже хотела, поэтому пошла на курсы. Выяснилось, что в этом компьютере кроме Word и Excel есть еще куча всего — процессор, память, конвейеры, устройства ввода-вывода. В итоге пошла «изучать компьютер» в ближайшем Московском инженерно-физическом институте, на факультете Кибернетики, на кафедре электронных вычислительных машин. На первых курсах у меня программирование шло довольно сложно, а в конце обучения прямо пёрло писать код. Под конец обучения я хотела стать программистом. Вечером садилась и писала код, а следующим вечером открывала глаза. Могла это делать сутками напролет. Но я поняла, что я человек увлекающийся, и решила выбрать что-то попроще. Всё шло довольно неплохо, программы работали. Но я осталась, и вот уже больше 20 лет этим занимаюсь. И пошла в эксплуатацию, а оказалось, что здесь тоже не просто, а даже местами сильно сложнее.
— Интересно, в какой момент принимаешь решение, быть программистом или админом?
Последние много лет я сталкиваюсь со студентами, и в «Яндексе», и в Mail. — По-разному. Люди в студенчестве приходят пробовать себя и в программировании, и в администрировании. Ru. Кто-то, поработав немного, переходит в разработку. Кто-то остается в эксплуатации и понимает, что это его. Есть какие-то пограничные случаи, которые сейчас называют модным словом DevOps. Кто-то, поработав в разработке, понимает, что хочет глубже разбираться в каких-то проблемах, узнать стек того, что находится ниже, под его программой, как она эксплуатируется, как живет, и погружается в эксплуатацию. Эти люди должны много знать и про железо, и про эксплуатацию, и про код.
А профессии эти очень сходны, во многом пересекаются. Всё зависит от человека, от того, что ему нравится и не нравится.
Расскажи подробнее. — Про тебя ходят легенды в «Яндексе», что в своё время у тебя был специальный рубильник, который в любой момент мог выключить один дата-центр, чтобы протестировать устойчивость системы.
Точнее, отключился один, но в нем находилось всё сетевое оборудование компании. — Эта история началась много-много лет назад с крупного инцидента: у «Яндекса» отключились практически все ЦОД. После этого была поставлена задача сделать всё надежным, отказоустойчивым, чтобы всё работало в случае отключения одного из ЦОД. «Яндекс» не работал несколько часов. Надежность стала гораздо выше, есть примеры, как современные ЦОД живут несколько дней на солярке. Сегодня эта проблема уже не так актуальна, особенно для коммерческих ЦОД. Но тогда было всё иначе.
Там, где это было невозможно или слишком сложно, мы обговаривали SLA (service level agreement). Несколько лет мы анализировали архитектуру всех приложений, писали планы задач, как и что надо сделать для обеспечения полной отказоустойчивости. Первое тестовое отключение было очень страшным. Основное внимание было приковано к популярным и высоконагруженным сервисам. Отключились и довольно быстро включились, записали все баги, доработали ряд систем. Половина сотрудников следили за данными мониторинга. И так несколько итераций.
Все понимали, что навык нужно поддерживать, регулярно проводить учения по отключению. Через какое-то время дошли до того, что могли спокойно прожить час-два, отключив один дата-центр. Поэтому мы регулярно открывали и закрывали «краны». Это как в сантехнике: если кран долго не открываешь, не закрываешь, то он закисляется, и в нужный момент его не откроешь. Я считаю достижением, что как-то раз мне ночью позвонили и сказали, что дата-центр упал, а я спросила, зачем меня разбудили 🙂 И это работало.
В какой момент программист может сказать, что он за это не отвечает, не знает, какая там база данных, это к админам. — Как ты думаешь, где проходит грань между программистами и системными администраторами? Или этой грани нет?
По-хорошему, он может залезть в код, посмотреть, как оно там устроено, как ему это чинить. — Мне кажется, что админ отвечает за приложение «от кончика носа до кончика хвоста». Он участвует в выборе технологии, потому что есть хорошие технологии для программистов, с ними очень удобно писать, но жить в режиме 24/7 с ними невозможно.
То есть разделение всё же есть. Программисты больше могут сосредоточиться на тех фичах продукта, которые им необходимы: дополнительная функциональность, дизайн, дополнительный код, который позволяет проекту лучше масштабироваться. Существуют разные теории, где и как должно проходить разделение ролей. В международной практике это Site Reliability и Software Engineer. Ru Group парадигма, в рамках которой есть эксплуатация и разработка, и это разные люди, работает довольно хорошо. Мне кажется, что принятая в Mail.
Ru Group. — Наверное, не все знают, как сейчас устроено в Mail. Расскажи подробнее.
Она состоит из нескольких отделов. — У нас есть служба эксплуатации, которая отвечает за работу сервисов. К примеру, Почтой занимаются несколько отделов: один хранилищем, другой вебом. Каждый отдел отвечает за конкретный продукт или группу продуктов, в зависимости от масштаба. А есть отделы, которые работают над несколькими проектами, масштабом поменьше.
Есть проекты, которые были запущены давно и являются нашими core-продуктами, например, Почта и Портал. В нашем хозяйстве — Почта, Поиск, Портал, Delivery club, «Юла», «Мой мир», ICQ и многие другие. А есть те, которые родились у нас и очень быстро выросли, например, «Юла». Есть купленные нами проекты, которые мы размещаем на своей инфраструктуре, обмениваемся с ними практиками эксплуатации. Хозяйство довольно разнообразное 🙂
Ru Group? — Как выглядит архитектура типичного сервиса Mail.
ЦОД как собственные, так и коммерческие, в коммерческих оборудование и сети у нас свои. — У нас несколько дата-центров. Суммарная емкость каналов у нас измеряется терабитами.
Большинство наших проектов — это веб-сайты. Мы размещаем серверы проектов в нескольких дата-центрах, чтобы отключение одного не влияло на работу сервиса. Архитектура стандартная: балансировщик нагрузки, под ним web-сервер, потом сервер приложений, а потом СУБД и/или хранилище.
Далее начинаются детали.
Например, для разработки и тестирования используется облако на OpenStack, где разработка и тестирование могут получить ресурсы по нажатию кнопки. В основном у нас всё живет на железных серверах, но и облака тоже есть.
Идет не быстро. Kubernetes внедряем, но этот процесс требует много чего менять в процессах как эксплуатации, так и разработки. Стараемся всё сделать аккуратно, чтобы ничего не сломать.
Для начала пользователь попадает на балансировщик. Вернемся к тому, что у нас происходит с пользователями. После чего web-серверы показывают пользователям красивые страницы, в основном, с помощью nginx и Apache. Для балансировки нагрузки используются сетевые протоколы BGP и RIP, и традиционное программное обеспечение — ipvs, haproxy и nginx.
Поскольку, как я говорила выше, есть и legacy, и довольно новые проекты, то языков программирования, на которых всё это написано, довольно много. А вот за ними стоят серверы приложений.
Пользователи не должны ощутить потери серверов какого-то хранилища или его части, мы стараемся бэкапить и реплицировать данные в соседние дата-центры. В качестве СУБД для новых проектов используются, в основном, MySQL, PostgreSQL и наша внутренняя разработка Tarantool.
Есть и свои разработки. В основном, мы используем оpen source, так как у нас в компании много программистов и инженеров, которые могут в любой момент что-то исправить. Например, хранилище, в котором лежат письма пользователей — своя собственная разработка.
— Сколько у тебя человек в подчинении?
Мы активно расширяемся, сейчас много открытых позиций. — Сейчас около 70, но это количество регулярно растет.
— Сколько серверов они обслуживают?
В основном в Москве, но также у нас есть серверы в других городах, в США и Европе. — Несколько десятков тысяч серверов, которые расположены в наших дата-центрах. Сами мы, конечно, не ездим в дата-центры, только разве что на экскурсии. За всем этим серверным парком нужно следить и ухаживать, обслуживать его.
— Какой же объем канала должен быть?
У всей Mail. — Несколько терабит. Возьмите хотя бы «ВК» и «ОК», которые показывают кучу видео, а ведь ещё есть Почта, Поиск, аналитика, и много других высоконагруженных сервисов. Ru Group общая сеть, по которой передается очень много информации. Поэтому сеть — важная составляющая.
— Что нужно знать, чтобы стать хорошим системным администратором?
Многие коммерческие компании сейчас используют эту ОС. — Конечно же, Linux. У всех свои предпочтения по дистрибутиву, мы используем CentOS. В основном внутри компаний стараются не использовать разные дистрибутивы, все стремятся к тому, чтобы он был один, так проще обновлять и поддерживать работоспособность систем. Так что в первую очередь нужно знать Linux, как и что там устроено, как устроено межпроцессное взаимодействие, как всё загружается и работает.
Кто-то специализируется на автоматизации, кто-то на веб-серверах, кто-то на сетях, кто-то на базах данных, а кто-то на облачных технологиях. Дальше идет специализация — кому что ближе и к чему лежит душа :-). Нужно понимать как работают приложения — уметь их настраивать, понимать плюсы-минусы применения того или иного приложения в задаче, ну и, конечно же, уметь его очень быстро чинить в случае проблем. Мне, например, в своё время очень нравились базы данных.
Примеры таких специализаций: сетевые инженеры разбираются в протоколах и знают, где и какие лучше применять, умеют настраивать глобальную и локальную маршрутизацию, знают, как обеспечить надёжность и отказоустойчивость сети.
Эти люди умеют посмотреть планы запросов, знают, зачем нужны индексы и какие они бывают. Специалисты по базам данных знают, как шардировать, реплицировать, бэкапить базу данных, чтобы надежно сохранить информацию и обеспечить высокую скорость работы.
Типичная задача: обсудить, почему запрос выполняется долго, надо и план посмотреть, и понять, нет ли проблем с загрузкой сервера (память, процессор, ввод-вывод).
Сложно ли тебе работать в мужском коллективе? — В общественном мнении админы представляются как ребята с большой бородой в растянутом свитере.
Во-первых, привыкла. — Сложный вопрос, потому что я работаю уже много лет. Во-вторых, если говорить про индустрию в целом, то уже было довольно много девушек в эксплуатации.
Мы до сих пор с подругой вспоминаем, как вдвоем вытащили большой, тяжелый, многоюнитовый сервер и поставили на пол, потому что отнести в специальное место для обслуживания уже не смогли. Такой миф исходит из далеких времен, когда требовалось много физической работы. Салазок тогда еще не было 🙂 И сидели на полу посреди дата-центра с отвертками, меняли диски.
Работаем в удобном офисе за столом. Сейчас такого нет. Наша работа сегодня ничем не отличается от работы программиста, которая тоже никогда не была чисто мужской: девушки-программисты — довольно частое явление.
Какой у тебя ноутбук? — Наш блиц-опрос.
— Apple.
— Что лучше, Bash или Perl?
— Bash.
— Стартап или большая компания?
— Стартап в большой компании.
— На что последнее тебе не хватило денег?
— На яхту.
Все сразу поймут уровень зарплаты в Mail. — Отличный ответ. Ru Group.
— Точно.
— ICQ или ТамТам?
— ICQ.
— «ВК» или «Одноклассники»?
— ВК.
— Кто твой кумир?
Я считаю, что многие люди и в российском, и в зарубежном интернете сделали довольно много для этой индустрии. — У меня нет кумира. Мне повезло, со многими из них я знакома лично. Благодаря им она развивается такими темпами.
— Назови крупных российских.
Если кого-то надо выделить лично, то рада, что в жизни получилось поработать с Ильей Сегаловичем. — Довольно много; опять же, боюсь, что всех не перечислю.
