Системный администратор свое дело

Куда расти сисадмину?

Куда расти сисадмину?

Владимир Зайцев

директор по клиентскому сервису NGENIX

В последнюю пятницу июля отмечают День системного администратора — в 2000 году опытного сисадмина Теда Кекатоса вдохновила позитивная реклама Hewlett-Packard, и он решил учредить день, который назвали System Administrator Appreciation Day. Разберемся, за что благодарить сисадминов, что это за люди, как развитие ИТ влияет на их роль, пора ли хоронить профессию и в каком направлении они могут развиваться.

Кто такой сисадмин?

Простой вопрос для тех, кто занят в организациях, использующих ПК и интернет (интересно, остались ли в мире те, кто еще нет? =)). Для них системный администратор — это человек, который поможет бухгалтерии с принтером, решит вопрос с упавшей сетью, обновит лицензии на рабочее ПО, обеспечит рабочее место, закупит необходимое оборудование. Получить смутное представление о том, чем занимается сисадмин, почему он бородат и в свитере и чем объясняется его любовь к котам, раньше можно было в основном на Башорге. Но Башорг уже не торт, так что поговорим об этой важной профессии с позиции взрослых людей.

В целом, основную задачу системного администратора можно описать просто: чтобы в организации все работало. Он применяет креативность и системное мышление, чтобы решить задачи, связанные с работой ИТ, наиболее оптимальным способом. В противоположность растиражированному образу в сетевом фольклоре, этот специалист должен обладать достаточно высоким уровнем эмпатии, чтобы услышать человека, у которого сбой в работе систем влияет на то, как сложится рабочий день и сможет ли он выполнить поставленные перед ним цели. У сисадмина также должно быть развито умение объяснить суть и решение проблемы человеческим языком, приняв как данность, что не все могут понять его с первого раза, и это нормально.

Так сисадмин или эникейщик?

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

Но технологии с каждым годом все прочнее входят в жизнь любой компании и становятся неотъемлемой частью ее работы, растет степень автоматизации и интуитивности инструментов. Растет и уровень технической грамотности сотрудников — для многих решить вопрос подключения к принтеру или обновить ПО уже не представляет из себя какую-то магию. С развитием облаков некоторые вообще прочат сисадминам как профессии вымирание, а на Хабре можно встретить множество жалоб на обесценивание и «опопсение» (честно, я цитирую нашего собственного сисадмина!) профессии, проблемы профессионального роста, рутинность задач. Совокупно все это влечет дискуссии о путях развития для системных администраторов.

Health Samurai , Санкт-Петербург, можно удалённо , От 130 000 до 200 000 ₽

Ребята, у вас все будет хорошо. В эту профессию попадают главным образом (ну, мы в это по крайней мере верим) пытливые и самообучающиеся люди, любящие технологии, следящие за их развитием, желающие докапываться до сути вещей, самостоятельно искать корень зла и решать проблемы. И для сисадмина существует множество путей, по которым можно пойти, если привычные задачи стали однообразными или хочется профессионального роста. Можно развиваться горизонтально и вертикально соответственно росту масштабов задач и ответственности, можно уйти в смежные направления, наработав новые скиллы. По сути, вы как будто заканчиваете школу, получив достаточное фундаментальное образование, и оттуда все дороги открыты — надо только выбрать (и да, я снова цитирую нашего сисадмина!).

Сетевой инженер (NetOps)

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

Какие знания нужно получить, чтобы администрировать крупные сети? В основном фундаментальные: стек TCP/IP, основы функционирования сетей, протоколы динамической маршрутизации, а также нужно познать особенности железа операторского класса различных вендоров (Cisco/Juniper/Mikrotik/Dlink/Huawei и других) — вряд ли вы столкнетесь на практике с гомогенными средами, так что придется хорошо ориентироваться в спецификациях железа и особенностях интеграции.

Инженер службы сопровождения

Это — привычный вам траблшутинг на максималках. Если говорить о нашей команде, наши инженеры сопровождают сложные высоконагруженные сервисы — это могут быть веб-сервисы крупных маркетплейсов, стриминговых платформ, государственных онлайн-платформ или телеканалов. Сисадминская мантра «чтобы все работало» здесь достигает абсолюта — от отказоустойчивости сервиса зависит счастье клиента, его репутация и деньги. И здесь особенно проявляются софт-скиллы, которыми должны обладать истинные системные администраторы — открытость, умение услышать и воспринять, докопаться до сути проблемы, желание помочь. Поэтому системные администраторы с этими качествами, при этом умеющие администрировать Linux, ориентирующиеся в стеке протоколов TCP/IP, HTTP(S), DNS, знакомые с nginx (предвкушая шутки — это не мы, а другие ребята) и пытливые достаточно, чтобы поковыряться в chef/puppet и поизучать матчасть в зарубежных источниках, у нас всегда востребованы и мы их постоянно ищем. Можно же чинить ноутбук секретаря, а можно траблшутить проблемы при работе с самыми популярными сервисами, решать нестандартные задачи и общаться с заказчиками уровня CTO =)

Технический аккаунт-менеджер

Представим, что компания продает сложный, кастомизируемый ИТ-продукт. Все по классике — разработчики разрабатывают продукт, продавцы (аккаунты) продают. Разработчикам хочется сконцентрироваться на том, что они делают лучше всего (кодят), а не общаться с потенциальными заказчиками, а аккаунты не способны так глубоко погрузиться в технические тонкости при анализе потребностей, чтобы правильно донести задачу до разработчиков. Чтобы этот канал коммуникации работал, нужен гибрид этих двух миров — Technical Account Manager (TAM).

В чем задача TAMа? Он связной, который «переводит» потребность клиента на язык разработчика, подбирает правильное с точки зрения технологии решение и следит за ходом внедрения, чтобы все остались довольны. ТАМ в тандеме с продавцом, который отвечает за коммерческую сторону процесса, должен предложить подходящую под задачи и требования технологию, кастомное решение, продукт, составить план внедрения, запустить пилот, проконтролировать реализацию, предложить улучшения.

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

Инженер в сфере информационной безопасности

Из года в год бизнес, вне зависимости от размера, все чаще подвергается кибератакам: в 2019 году в 81% случаев пострадали юрлица — главным образом, госучреждения и финансовые организации, предприятия сферы медицины, образования и науки (это из последнего отчета Positive Technologies). Учитывая, что у нас в стране в последние годы активно цифровизируются даже самые олдскульные представители гос-ИТ и параллельно появляются все новые киберпреступные способы усложнить жизнь компаниям, тому, кто решит посвятить себя информационной безопасности, есть где развернуться, и спрос на таких специалистов растет, не поспевая за темпами развития угроз.

Сисадмину, уже хорошо знающему устройство ИТ-инфраструктуры, понимающему важность своевременного обновления ПО, разграничения прав доступа, восстановления после сбоев, можно пойти намного дальше, чем установка антивируса на ПК пользователей. Я вот не знаю ни одного толкового ИБ-шника, который не хлебнул до этого всех прелестей сисадминской жизни.

Что важно и чему понадобится научиться сисадмину, чтобы специализироваться в инфобезе? Конечно, в серьезном месте у вас попросят признанные сертификаты — например CompTIA Security+ или CISSP (Certified Information System Security Professional). Важно учиться фундаментальным вещам и уделять особое внимание не только изучению систем защиты, но и практикам этичного хакинга (взломам и эксплуатации уязвимостей). И еще понадобится немного «убить» своего внутреннего сисадмина: обычно основная задача сисадмина в организации — сделать так, чтобы все работало, и быстро, но для ИБ-инженера приоритет всегда состоит в надежности, а это всегда предполагает ограничения в способах решить задачу.

DevOps-инженер

Классический системный администратор собирает ИТ-систему из уже готовых hardware- и software-элементов и делает так, «чтобы все работало»: устанавливает обновления, проводит регламентные операции и так далее. Но при этом он не имеет отношения к процессам разработки и эксплуатирует код, который ему предоставили — то есть, Ops в чистом виде. Опыт на стороне эксплуатации в сочетании с погружением в процессы разработки и владением рядом специализированных методологий и инструментов позволяет системному администратору развиваться в сторону DevOps-инженера — весьма востребованного и высокооплачиваемого специалиста в сегодняшнем мире сложных архитектур и высокой скорости разработки.

Его задача, как и у системного администратора, — сделать так, «чтобы все работало», но в случае с DevOps она имеет дополнительные уровни сложности: DevOps-инженер не только обеспечивает стабильную работу production-систем, но и отвечает за то, чтобы все процессы разработки и эксплуатации были максимально оптимизированы и эффективны — то есть, чтобы разработчики писали код уже с учетом тонкостей архитектуры и особенностями нижележащей инфраструктуры, не тратя свое дорогое время на «мартышкин труд», а рутинная работа по эксплуатации была максимально автоматизирована.

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

Чтобы выполнять функции DevOps-инженера, потребуется довольно много постичь и уметь объединить в себе часть процессов разработки и часть процессов эксплуатации. Кроме того, нужно научиться уверенно оперировать разнообразными инструментами от Jira до инструментов выстраивания CI/CD-пайплайнов типа Jenkins и Gitlab CI/CD, от инструментов мониторинга вроде Zabbix и Prometheus до инструментов управления конфигурациями вроде chef/puppet/ansible. Также DevOps-инженер использует разнообразные средства автоматизации и оркестрации — всего не перечислить. Все это накладывается на ряд важных софт-скиллов, которые могут обнаружить в себе системные администраторы: готовность к постоянному развитию, стремление отладить и автоматизировать работу себя и других людей и процессов, аналитический склад ума.

Системный архитектор

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

Системный архитектор анализирует технологическое направление развития организации и определяет наилучшие технологии и решения для создания ИТ-инфраструктуры с учетом бюджета и масштабирования. Он исследует, определяет и тестирует необходимые решения, разрабатывает и документирует стратегии интеграции и миграции. В некоторых аспектах задачи системного архитектора пересекаются с системным администрированием, но уровень повышается: теперь это не «сделать так, чтобы работало», а «спроектировать то, что будет работать».

Сложно определить, какими именно техническими компетенциями должен обладать системный архитектор — очень многое зависит от стека технологий и задач организации. Например, на одном месте работы ему могут потребоваться глубокие познания в работе сети и различного оборудования операторского класса, сред виртуализации, СУБД, СХД и даже регуляторных требований. Но это будет варьироваться от случая к случаю. Системный архитектор должен уметь грамотно, структурированно и логично излагать мысли (привет, сисадминские софт-скиллы), обладать знаниями методологий проектирования, средств проектирования, принципов интеграции систем. Да, если вы не обладаете опытом администрирования сложных ИТ-инфраструктур, для вас это будет долгий путь. Но все возможно с приобретением опыта и дополнительных навыков =)

Итак, я перечислил очевидные опции — как с низким, так и с высоким порогом входа — но это далеко не все. Есть тип людей, склонных наращивать компетенции горизонтально в темпе роста компании и развития технологий — то есть, начав с поддержки локальной сети, через время уже разбираться с миграцией в облако. А если говорить про вертикальный рост, я даже лично знаю человека, который вырос из системного администратора в CTO – наберется на отдельную статью. Есть и бесчисленное множество системных администраторов, открывших собственный бизнес или успешно работающих в сфере ИТ-консалтинга. Так что зачем хоронить профессию, которая открывает столько перспектив?

Источник

Oh, my code. Как стать системным администратором

Заместитель технического директора 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, как и что там устроено, как устроено межпроцессное взаимодействие, как всё загружается и работает.

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

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

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

Типичная задача: обсудить, почему запрос выполняется долго, надо и план посмотреть, и понять, нет ли проблем с загрузкой сервера (память, процессор, ввод-вывод).

— В общественном мнении админы представляются как ребята с большой бородой в растянутом свитере. Сложно ли тебе работать в мужском коллективе?

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

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

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

— Наш блиц-опрос. Какой у тебя ноутбук?

— Что лучше, Bash или Perl?

— Стартап или большая компания?

— Стартап в большой компании.

— На что последнее тебе не хватило денег?

— Отличный ответ. Все сразу поймут уровень зарплаты в Mail.Ru Group.

— «ВК» или «Одноклассники»?

— У меня нет кумира. Я считаю, что многие люди и в российском, и в зарубежном интернете сделали довольно много для этой индустрии. Благодаря им она развивается такими темпами. Мне повезло, со многими из них я знакома лично.

— Назови крупных российских.

— Довольно много; опять же, боюсь, что всех не перечислю. Если кого-то надо выделить лично, то рада, что в жизни получилось поработать с Ильей Сегаловичем.

Источник