Александр Рябов: «В ИТ, как в хорошем приключении, надо не слушать рассказы, а участвовать самому»::Журнал СА 9.2017
www.samag.ru
     
Поиск   
              
 www.samag.ru    Web  0 товаров , сумма 0 руб.
E-mail
Пароль  
 Запомнить меня
Регистрация | Забыли пароль?
Журнал "Системный администратор"
Журнал «БИТ»
Наука и технологии
Подписка
Где купить
Авторам
Рекламодателям
Магазин
Архив номеров
Вакансии
Контакты
   

  Опросы
1001 и 1 книга  
12.02.2021г.
Просмотров: 8881
Комментарии: 2
Коротко о корпусе. Как выбрать системный блок под конкретные задачи

 Читать далее...

11.02.2021г.
Просмотров: 9220
Комментарии: 5
Василий Севостьянов: «Как безболезненно перейти с одного продукта на другой»

 Читать далее...

20.12.2019г.
Просмотров: 16376
Комментарии: 0
Dr.Web: всё под контролем

 Читать далее...

04.12.2019г.
Просмотров: 15430
Комментарии: 13
Особенности сертификаций по этичному хакингу

 Читать далее...

28.05.2019г.
Просмотров: 16468
Комментарии: 6
Анализ вредоносных программ

 Читать далее...

Друзья сайта  

Форум системных администраторов  

sysadmins.ru

 Александр Рябов: «В ИТ, как в хорошем приключении, надо не слушать рассказы, а участвовать самому»

Архив номеров / 2017 / Выпуск №9 (178) / Александр Рябов: «В ИТ, как в хорошем приключении, надо не слушать рассказы, а участвовать самому»

Рубрика: Разработка /  DevOps

Александр Рябов:
«В ИТ, как в хорошем приключении, надо не слушать рассказы, а участвовать самому»

В гостях у «Системного администратора» Александр Рябов, DevOps-инженер в компании Intermedia

Александр Рябов
Александр Рябов, единственный обладатель компьютера (ZX Spectrum) в школьные годы в родном поселке в Крыму. Переехал в Санкт-Петербург в поисках интересной работы. Сприходом диалап-интернета увлекся идеологией Open Source. Github member c 2012 года, до этого распространял свой софт в архивах вместе с папкой /src. Принимал участие впостроении ИТ-проектов как в госорганах (ЕЦД), так и за рубежом (Швеция). В данный момент занимается проблемами, связанными с ежегодным удвоением количества Linux-серверов на позиции DevOps Engineer в компании Intermedia

– Александр, расскажите, чем вы занимаетесь в Intermedia?

– В компанию Intermedia я пришел как системный администратор Linux четыре года назад. В тот момент позиций DevOps у нас еще не было. Было четкое разграничение наDevelopment и Operations, и Linux SA отвечали за всю Linux-инфраструктуру компании.

Здесь, наверное, стоит немного отвлечься и упомянуть, чем вообще занимается компания, чтобы понимать масштаб. Началось все с hosted MS Exchange для малого и среднего бизнеса, и до сих этот продукт является одним из самых больших в компании. Потом был hosted SharePoint, Lync и Web hosting. Для почты был реализован свой антиспам, и стали разрабатываться уже свои продукты, которые востребованы небольшим бизнесом – телефония, бэкапирование, единая аутентификация и т.д. Одним из последних появился SecuriSync – наш аналог dropbox, c функционалом, специфичным для бизнес-пользователей.

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

В этом помогал наш внутренний configuration management, инструмент, написанный еще до chef и ansible. Поначалу он мне понравился, но потом пришло понимание, что егоналичие вредит. Это хороший пример для демонстрации разницы в подходах, давайте остановлюсь на нем поподробнее.

Инструмент был написан нашими Windows-разработчиками и располагался, соответственно, в вотчине, недоступной Linux SA. Любое изменение или багфикс занимало очень большое количество времени, т.к. коммуникация между Development и Operations проходила посредством кейсов. Так получалось, что те люди, которые разрабатывают инструмент, не пользуются им. А те, кто пользуются, не могут его изменять.

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

Я начал разбираться с альтернативами и переписал костяк нашего инструмента на ansible. Этого было достаточно, чтобы начать пользоваться и сделать презентацию коллегам. На тот момент идея особого распространения в отделе не получила. Я же продолжил переносить конфигурацию в ansible и все больше осознавал его недостатки. В то время последняя версия была 1.8, еще до execution strategies. Те, кто пытался запустить playbook из хотя бы 50 шагов на 100 серверах, понимают, о чем я говорю.

Из имеющихся альтернатив были опробованы puppet и chef, и выбор пал на последний. Порог вхождения в эти системы, конечно, несравним с ansible, но оно того стоит! Так я стал делать билды новых серверов в разы быстрее, чем с использованием нашего внутреннего инструмента.

Как только удалось снизить время переконфигурирования сервера, сразу стали очевидны наши следующие проблемы. Изменения в DNS/DHCP и системы IPAM вносились вручную, и эти системы не имели синхронизации или единого API между собой. Так появилась тонкая обертка для наших внутренних систем, которая, с одной стороны, предоставляла единый REST API, а с другой – ходила в web interface или напрямую в базу и совершала необходимые действия. Это сделало возможным полностью автоматическое создание новой виртуалки с нуля.

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

Сейчас я DevOps в продукте SecuriSync (тот самый dropbox) и занимаюсь всеми вопросами, связанными с инфраструктурой и CI/CD, также включая релизы и Production. Основная задача – делать так, чтобы увеличение количества серверов не приводило линейно к увеличению количества людей. То есть отнимаем у человека все, что можно доверить роботу. Тут также находится основная мысль SRE – я смогу это делать, только когда у меня есть время на кодинг, т.е. необходимо следить, чтобы мониторинг и рутина не отнимали больше 50% времени.

– Можно ли узнать подробности архитектуры SecuriSync? Какие языки и технологии использовали для реализации?

– Сейчас у нас есть клиентские приложения для Windows, Mac, iOS, Android, BlackBerry и Web (SPA Angular), которые работают с backend (BE). Снаружи BE представляет собой набор REST-сервисов и асинхронную шину сообщений WebSocket. Внутри используются nginx + uwsgi и асинхронные сервисы на базе Tornado, MySQL, RabbitMQ, ElasticSearch наDebian Linux. Для хранения пользовательского контента – EMC и Amazon S3. Весь код на Python, интеграционное тестирование – на Python и Perl, нагрузочное – на Java (JMeter).

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

У нас есть несколько инсталляций SecuriSync BE – дюжина development, pre-production, internal для бета-тестирования, пара в США и одна в Ирландии (AWS) для европейского рынка. Обсуждаются новые инсталляции в Гонконге и Австралии.

Почему MySQL, а не NoSQL (couchbase, MongoDB, redis, tarantool)? Второе поколение SecuriSync мы начинали разрабатывать на Couchbase, но столкнулись с необходимостью ACID-транзакций и сложностями при интенсивной смене схемы данных. В качестве быстрой замены выбрали знакомый нам MySQL. В наших планах начать использовать NoSQL (возможно, redis) для задач, где преимущества NoSQL очевидны.

Почему MySQL, a не PostgreSQL/Oracle/MS SQL/Terradata? Как нам кажется, MySQL больше подходит для нашей задачи – огромное количество маленьких транзакций (в основном по primary key). Опыт Facebook, VKontakte, YouTube, Dropbox, Box.net, Twitter и других компаний говорит о том, что выбор не самый плохой.

– Что для вас «работа по принципам DevOps»?

– Для меня это просто Operations, как если бы им занимались девелоперы. Это неизбежно приходит, когда количество серверов измеряется в сотнях на сисадмина. Infrastructure as acode, microservices для масштабирования, CI/CD, API для всего – не просто модные термины, а путь к выживанию. AWS – это хороший пример как должна выглядеть ваша инфраструктура изнутри. Представьте: вы нажимаете на кнопку Create EC2 instance, а это создает тикет для админа, который идет руками создавать виртуалку в VMware. Вряд ли такой амазон смог бы скейлиться так же хорошо, как реальный.

– На ваш взгляд, есть ли преимущество Open Source при использовании методологии DevOps?

– На мой взгляд, есть преимущество Open Source при использовании любой методологии. DevOps – то про автоматизацию и постоянные изменения (итеративные). И только воткрытых продуктах ты можешь добавить нужный для автоматизации функционал или поправить баг сам, не вступая в долгую переписку с вендором, которая может окончиться ничем. Нет постоянной зависимости от третьих лиц.

– Расскажите про мониторинг?

– У нас несколько офисов в разных точках земного шара, и мы используем подход follow the sun, временные зоны перекрываются, таким образом, есть сисадмин на мониторинге24/7. Для мониторинга у нас используется Zabbix из-за своих возможностей гибкой настройки алертов. Считается, что для мониторинга сервиса достаточно следить всего зачетырьмя параметрами:

  • Latency. Время, которое занимает обработка запроса. Неплохо бы разделять время для корректных ответов и ошибок.
  • Traffic. Количество запросов, приходящих к сервису. Например, rps для http-сервисов или bandwidth для стриминга.
  • Errors. Запросы, обработанные с ошибками.
  • Saturation. Насколько заполнен сервис. Например, для диска это общий объем и занятое место.

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

Для расследования инцидентов захотелось иметь возможность быстро окинуть взглядом все графики с хоста на одной странице. Была опробована grafana с Zabbix в качестве datasource, но скорость работы оставляла желать лучшего, т.к. Zabbix API не поддерживает downscaling. Так что в лучших традициях Open Source был написал плагин ZabbixGrapher, который позволяет динамически рисовать много графиков с хоста или группы или несколько айтемов на одном графике.

Также мы очень плотно пользуемся фичей Low Level Discovery в Zabbix, и стало не хватать возможности рисовать все найденные LLD айтемы на одном графике. Это тоже удалось поправить, был написан плагин gLLD. Оба плагина доступны у меня на github.

В данный момент мы достигли пределов вертикального масштабирования Zabbix и активно присматриваемся к альтернативам. Graphit – возможный претендент, если удастся решить проблему алертов.

Другой источник нотификаций – это мониторинг логов. Для этого мы используем Splunk. Это действительно всеядная система, с простым и мощным языком запросов.

– Какие сервисы используете для разработки?

– Основная ALM (Application Lifecycle Management) система, которую мы используем для планирования, баг-трекинга, оркестрирования билдов/тестов, – это Microsoft TFS. (Тут, наверное, сказывается история компании и то, что мы золотой партнер Microsoft.)

Вообще для разработки используется адаптированный под наши нужды Agile и четырехнедельные итерации. В качестве VCS используем git, и это также часть TFS. Pull requests дляpeer code review, ветки для разработки фич – в общем, по сути, gitflow с небольшими особенностями. Например, разработчики не делают свои форки репозитория, а работают ведином.

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

Для развертывания тестового окружения, в том числе и на машине разработчика, используем vagrant-lxc. В данный момент я занимаюсь переводом проекта в Docker.

Для документирования информации между отделами в компании используется Atlassian Confluence.

А вот для документирования инфраструктуры используем Chef. Такая информация получается всегда up to date, и ей можно доверять. Также гарантируется, что Dev и Prod всегда сделаны по одним чертежам.

– Какие инструменты используете для разработки (среды, ОС и т.п.)?

– Каких-то специальных требований нет. Есть разработчики, которые используют Windows и PyCharm. Есть такие, которые пишут в Linux и geany или VScode. Здесь кому какудобнее, и этому способствует то, что тестовое окружение в контейнерах и разворачивается на локальной машине за пять минут. ALM-система доступна через веб-интерфейс, и дляработы с ней нужен лишь браузер. Были случаи, когда разработчики из отпуска коммители код прямо в онлайн-редакторе TFS.

По приходу в компанию я получил хорошую рабочую станцию на Windows и три монитора. Но по прошествии времени переехал на Mac. Не хочу сказать, что Windows хуже илилучше – в свое время я вложил много времени в улучшение тулинга для винды. Какая-то часть доступна у меня на github.com/sepich. Наоборот, мне кажется, хорошо, когда ты непривязан к платформе и можешь продуктивно работать в любом окружении. В данный момент, мне кажется, я более продуктивен на MacBook Pro и двух мониторах. В качестве редактора – Sublime Text.

– В чем для вас преимущества Sublime Text? Использовали ли Atom, Microsoft Visual Code?

– Да, эти продукты я пробовал. А также большую часть более старых альтернатив, потому как давно повернут на подсветке синтаксиса. В те времена, когда Total Commander еще назывался Windows Commander, я написал плагин подсветки кода в Lister – Syn. Потом был Syn2, который впоследствии отлично развил Алексей Торгашин как SynWrite. Я же переключился на менеджер заметок для кодера SynNotes, который доступен у меня на github.

А на Sublime сейчас потому, что начал его использовать еще до эпохи electron. VScode на самом деле у меня стоит вторым редактором, иногда его использую для js и markdown preview. Нравится инициатива Atom по переписыванию ядра на С++, может, из этого выйдет что-то хорошее.

– Какое ПО предпочитаете для повседневного использования (браузеры, почтовые клиенты, редакторы и т.п.)?

– Корпоративная почта у нас – Microsoft Exchange, так что почтовый клиент у большинства – Outlook. У минималистов – OWA. Причем в плане почты, наверное, будет интересным то, что мы являемся своим же клиентом. То есть почта нашей компании хостится вместе с почтой наших клиентов и ничем не отличается. Принцип eat your own dog food в действии.

Для начинающих свой путь в ИТ хотелось бы упомянуть, что в компаниях всегда открыты вакансии в Support с минимальными требованиями. Я считаю, это отличный старт длястудентов, т.к. присутствуют гибкий график и обучение

По браузерам: у нас в отделе я был последним человеком, использующим Firefox как основной браузер. Но несколько месяцев назад и я переехал на Chrome – так что личным примером подтверждаю его лидерство на десктопах. Обычно это не очень хорошо для развития, когда какую-то нишу занимает только один продукт, но пока, к сожалению, у«Хрома» нет конкурентов.

По аналогии с почтой для общения внутри компании мы использовали Lync. Потому что продавали его как сервис клиентам. Потом это был Skype for Business. Даже был опыт написания бота, помогающего с информацией по кейсам и change management.

Сейчас акцент Microsoft сдвинулся в сторону Office 365, и потому мы перешли на Microsoft Teams. Это такой аналог Slack, и интеграция с ним также проста. Есть хорошо документированный REST API и поддержка WebHooks, интеграция с TFS.

– Почему Google Chrome? Какие именно его возможности определили ваш выбор?

– Больше повлияло не наличие чего-то в «Хроме», а методическое искоренение возможностей в Firefox. Хороший свежий пример: все плагины, которые не успевают перейти наWebExtensions, в 57-й версии в ноябре остаются за бортом. Но решающим фактором было то, что некоторые некачественные сайты (например, онлайн-банк) перестали корректно отображаться. Видимо, доля Firefox упала так низко, что веб-разработчики уже перестают тестировать сайты на совместимость с ним.

– В каких проектах вы принимали участие? Поделитесь интересными, запомнившимися случаями из опыта разработки.

– Это очень трудный вопрос, потому что у нас все время происходит что-то интересное. Например, сегодня я запускал команду mv для папки размером 2 Pb. И я не уверен, чтозапомню это надолго. Тут, как в хорошем приключении, надо не слушать рассказы, а участвовать самому.

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

Подготовил Игорь Штомпель


Комментарии отсутствуют

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

Комментарии могут оставлять только зарегистрированные пользователи

               Copyright © Системный администратор

Яндекс.Метрика
Tel.: (499) 277-12-41
Fax: (499) 277-12-45
E-mail: sa@samag.ru