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