 |
|
|
|
Александр Рябов: «В ИТ, как в хорошем приключении, надо не слушать рассказы, а участвовать самому»
Александр Рябов: В гостях у «Системного администратора» Александр Рябов, DevOps-инженер в компании 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 из-за своих возможностей гибкой настройки алертов. Считается, что для мониторинга сервиса достаточно следить всего зачетырьмя параметрами:
И поначалу этого хватало, но со временем происходили разные инциденты, для дебага которых все время не хватало какой-то дополнительной информации. Ее добавляли, количество графиков на каждый сервис увеличивалось. Для расследования инцидентов захотелось иметь возможность быстро окинуть взглядом все графики с хоста на одной странице. Была опробована 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 в действии.
По браузерам: у нас в отделе я был последним человеком, использующим 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. Также вы можете стать админом серверов, минуя шаг админ небольшой компании/офиса. Подготовил Игорь Штомпель |
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
