`

СПЕЦИАЛЬНЫЕ
ПАРТНЕРЫ
ПРОЕКТА

Архив номеров

Что для вас является метрикой простоя серверной инфраструктуры?

Best CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Игорь Шаститко

SysAdmin vs DevOps – что разного и что общего

+55
голосов

DevOps — одно из модных сейчас «поветрий» (наряду с «data scientist» и прочими «IoT» и «AI»), адепты которого активно продвигают мысль, что «все ИТ будет devops» — в прогрессивной ИТ-среде не останется системных (и прочих) администраторов, их таки заменят DevOps. НО, самое интересное, что даже внутри крупных ИТ корпораций, которым тренд «DevOps» приносит большие прибыли, нет единого мнения о судьбе в современных ИТ-инфраструктурах тех позиций, которые в общем называли «ИТ-профессионалы» и которые в реальности к «Dev» вообще не прикасаются, а управляемые ими инфраструктуры настолько статичны, что их «Ops» не меняются годами и выполняются рутинно (я это называю «ребята нашли свой карман безделья»).

Потому, в данной презентации со Стального Бубна 2018 во Львове, посвященной концепции Infrastructure as Code (IaC) для системных администраторов и архитекторов ИТ-инфраструктуры, я попытался (как оказалось, даже 1,5 часа очень и очень мало, чтобы рассказать и показать самые базовые концепции) сравнить те задачи, которые решают DevOps и SysAdmin, что у них отличного и, главное, что есть общего в работе и DevOps, и SysAdmin — какие современные тенденции на рынке управления ИТ-инфраструктурами позволяют использовать общий инструментарий и общие подходы в работе SysAdmin и DevOps. И все это, конечно же, на примере облачных технологий, связанных с Microsoft Azure.

Начнем, пожалуй, с того момента, что важность и потребность в позиции «DevOps» достаточно сильно «культивирована» теми компаниями, которые, собственно, продают инструменты для работы DevOps или компаниями-аутсорсерами, где DevOps — производственная необходимость в рабочем процессе с постоянным «выкатыванием» новых сборок ввиду забажености кода, производимого гребцами галер. Да и, собственно, сейчас какие только позиции и обязанности не называют красивым именем «DevOps». В реальности ситуация с DevOps примерно такая же, как с той картинкой про айсберг — DevOps сейчас — одна из самых «видимых» позиция в ИТ-индустрии, не считая девелоперов (потому что их раньше не было, точнее — не придумали еще такое слово, и технологии были «пожиже», а теперь они срочно нужны каждому уважающему себя аутсорсеру), а основное управление ИТ-инфраструктурой «обычных» компаний по прежнему лежит на плечах обычных таких системных администраторов, которые работают себе с этой самой инфраструктурой «по старинке». Я лично, и моя компания как раз оказывает услуги таким вот «обычным» компаниям и сейчас в тренде — это миграция части ИТ инфраструктуры в облака с последующим обновлением (читай — rebuild до архитектуры, близкой к требованиям PaaS) некоторых LoB решений компании или же — использование облачных сервисов типа Azure Backup или Azure Site Recovery для реализации более эффективного резервного копирования или защиты от сбоев. И у меня накопилась достаточно большая и релевантная статистика отношения руководителей (CIO, CEO) к концепции DevOps для работы с их ИТ-инфраструктурой.

Но перед тем, как продолжить тему Infrastructure as Code — рекомендую познакомиться с моим докладом на предыдущем Стальном Бубне, который подробно рассказывает, что бывает, когда DevOps используют (или они берутся сами за работу) не по прямому назначению — как архитекторы и администраторы ИТ-инфраструктуры обычной компании с ее обычными сервисами + немного облаков.

Итак, вернемся к отзывам обычных компаний про место DevOps и соответствующих процессов в их ИТ-инфраструктуре (комментарии собирательные, но некоторой — очень близко к тексту):

  • У нас нет разработки, у нас стабильная инфраструктура, которая нуждается в базовых рутинных операциях.

  • Мы планируем перенос инфраструктуры в облако, верно, но это будут реплики наших виртуальных машин или базовые сервисы.

  • Скрипты? Извините, но мои люди получают заплату за то, чтобы работали сервисы.

  • У нас рутинные операции, если надо — есть RDP/TeamViewer и прочие инструменты админа.

  • DevOps — это какие-то аутсорсеры, которых мы наняли для написания приложений, они работают в своей песочнице и инфраструктуры это не касается.

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

Текущие тенденции в экономике и бизнесе — говорят, что нет... Хотя бы потому, что все идет, как обычно — нужно дешевле, быстрее и на вчера. В том числе — и в управлении ИТ-инфраструктурой. Быстрее развертывать новые сервисы, восстанавливать старые, подключать быстрее и больше пользователей и выдавать им данные на их запрос как можно оперативнее, а лучше всего — дать пользователю кнопку «сделать весь отчет/презентацию/работу за меня» ;) И да! — Еще и параноидальная безопасность во всем + новое красивое слово GDPR (под которое можно подвести любые требования).

И, самое главное — компаниям упорно продают облака... Мировые гиганты в ИТ вкладывают в этот сегмент громадные деньги, в том числе и на маркетинг, что приводит к тому, что любой CIO задумывается над вопросом «а зачем мне облака?» и даже если не задумывается — ему обязательно напомнит его CEO вопросом типа «а что у нас там с облаками? Мне тут рассказали, что это на 30% эффективнее нашей текущей системы». Нет, я ничего против облаков не имею, и даже сам придумаю 10-15-20 причин, почему облака лучше локальной инфраструктуры — я просто озвучиваю тенденции и текущий момент раздумий CIO.

В результате сейчас сложилась ситуация, которая довольно патовая и для руководства ИТ-инфраструктур, и для сисадминов, и даже для тех самых корпораций, которые «пропихивают» массы в облака. Почему? Да потому что сейчас как бы существует 2 мира ИТ-инфраструктур, в одном из которых есть серверы с их консолями, традиционные системы и процедуры управления (от тех самых компаний, которые и «за облака»), а во втором — есть облака с совершенно другой концепцией управления, вроде как изначально заточенной под девелоперов и DevOps (что не принимается CIO/сисадминами — смотри выше) и в которые надо поместить путем «взяли и переставили» существующие серверы с нестыкующейся моделью управления внутри. И основные проблемы тут:

  • Традиционные модели управления устаревают ввиду новых облачных технологий и требований.

  • Очень много ручной работы и модификаций + еще один уровень абстракции в виде облака.

  • Ручное тестирование современной инфраструктуры требует больших затрат в целом и слишком затратно по времени.

  • Административные привилегии предоставляются без детализации задачи, ограничений по времени.

  • Операционные команды не накапливают опыт в виде готовой документации и повторяемых конфигураций — метод next-next-next этого не позволяет ;)

Потому общую тенденцию в изменении требований к управлению «обычной» ИТ-инфраструктуры «обычными» системными администраторами можно озвучить, как:

НОВЫЕ ПОДХОДЫ К УПРАВЛЕНИЮ ИТ ИНФРАСТРУКТУРОЙ ТРЕБУЕТ БОЛЕЕ ТОЧНЫХ, АВТОМАТИЗИРОВАНЫХ ПРОЦЕССОВ С ОБШИРНЫМИ ВОЗМОЖНОСТЯМИ ПО ДЕКЛАРАТИВНОМ ОПИСАНИЮ, ПОВТОРЕНИЮ И МАСШТАБИРОВАНИЮ, НЕЖЕЛИ СЕЙЧАС.

Как будут выглядеть ИТ-инфраструктуры будущего даже в «обычных» компаниях, которые соответствуют указанным требованиям и какой будет работа системного администратора, управляющего такой ИТ-инфраструктурой? — Правильно, как уже знакомое для DevOps понятие Infrastructure as Code со всеми вытекающими отсюда свойствами и возможностями:

  • Инфраструктура определяется как набор декларативных описаний объектов...

  • Которые сохраняются в конфигурационных файлах...

  • Точно описывающих установку отдельного сервера или всего окружения...

  • С «идемпотентностью» (вот же слово придумали)...

  • С автоматизацией конфигурирования и рутинных операций...

  • С сохранением ИТ администраторских навыков и инструментов...

  • + внедрения процедур, применяемых в разработке ПО — Source/Build/Test/Release

Что изменится в результате распространения концепции Infrastructure as Code для системных администраторов не только в облачных ИТ-инфраструктурах, но и в их локальных сетях и любимых продуктах, а также в самих процедурах работы с ИТ-инфраструктурой в средних и крупных компаниях?

  • Распространение концепции декларативной Infrastructure as Code на локальные инфраструктуры (например, с распространением Azure Stack).

  • Перенос большинства сервисов управления и мониторинга в облака (уже сейчас активно развиваются облачные Microsoft Intune и Operations Management Suite) с применением к ним возможностей управления через конфигурацию.

  • Автоматизация работы облачных, гибридных и локальных с использованием облачных сервисов типа Azure Automation и гибридных runbook.

  • Постепенный дрифт AD в сторону Azure AD + Desire State Configuration (DSC), который придет на замену привычных групповых политик (учим DSC уже сейчас).

  • Повышение требований Business Continuity / Disaster Recovery и, как результат, более активное использование в компаниях таких средств, как Azure Backup и Azure Site Recovery — готовой песочницы для того, чтобы при крупной катастрофе локальной инфраструктуры компания «рывком» оказалась в облаках (и вы даже не представляете, какая будет паника у ИТ после этого!).

  • Иметь 2-3 параллельные идентичные инфраструктуры будет нормой — что позволит быстро вводить в эксплуатацию новые решения или реагировать на катастрофы.

  • И да, концепт на то, что в нынешних условиях дешевле все с нуля пересобрать, развернуть или переключить несколько слотов развертывания с использованием декларативных шаблонов, описанных выше — чтобы быстро обеспечить бизнесу работу служб — а после искать ошибки, которые привели к сбоям или остановке предыдущей.

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

Итак, перспективы развития облачных, гибридных и даже локальных ИТ-инфраструктур и подходов управления ими в ближайшие годы понятны. Что делать системному администратору, который осознал, что его умение создать, настроить виртуальную машину и установить внутрь нее ОС с настройкой ролей этой ОС и даже детальных отдельных сервисов, типа вебсайта — скоро окажется невостребованным по причине замены этих навыков новыми инструментами? Есть много ответов на этот вопрос, например — «уйти из ИТ», или «переквалифицироваться в DevOps», или «в бьюти-/тревел-блогеры» (ага, это троллинг самого себя, у автора достаточно большое количество видео, посвященных путешествиям — «Путевые Заметки Игоря Шаститко» — http://bit.ly/iwalker2000_travels1 ), или «просто развиваться и постараться взглянуть на способы администрирования ИТ-инфраструктур под другим углом». И изучать новые технологии и инструменты управления, которые уже есть на рынке, и которые используют те же DevOps (так что, если хотите в DevOps — учиться придется еще больше и тому же). А именно:

  • Шаблоны описания конфигураций — Azure Resource Manager templates (ARM, доступен и в локальных облаках Azure Stack).

  • Средства развертывания инфраструктур из шаблонов и просто скриптами — портал Azure, Azure PowerShell, Azure CLI, VS, GitHub.

  • Средства контроля конфигураций — Desire State Configuration (DSC) — и не только в базовых сценариях, но и в сочетании с теми же шаблонами ARM.

  • Облачные средства автоматизации и мониторинга — такие, как Azure Automation, Hybrid Runbook Workers, Operations Management Suite и прочие реакции на события и т.п.

  • Средства управления исходным кодом шаблонов, скриптов развертывания, runbook, DSC, с интеграцией Azure с GitHub и прочими решениями.

  • Средства управления процессом разработки ИТ-инфраструктуры с подходом Infrastructure as Code — Source/Build/Test/Release — с применением тех же облачных сервисов Visual Studio Team Services и т.п.

И, после такой вводной части — рекомендую все же посмотреть полную запись моего выступления на конференции «Стальной Бубен» во Львове в мае 2018 — «Автоматизация развертывания и конфигурирования VM в IaaS Azure — взгляд со стороны админа, а не DevOps» — кроме, собственно, слайдов системные администраторы найдут в этом видео примеры использования всех перечисленных технологий и инструментов. Да, как я уже писал, я немного просчитался со временем, к сожалению, опыт показал, что для подобной презентации с демо потребуется минимум в 3 раза больше времени, потому я планирую включить все эти демо в запланированную на своем канале серию, посвященную работе системного администратора с Microsoft Azure.

Выводы? Для системных администраторов — они не утешительные — «учиться, учиться и еще раз учиться» — вас ждет «большая ломка» — методов, инструментов, и собственно, того, чем вы будете управлять. Потому — всех действительно заинтересованных ожидает очень интересная дорога вперед, перед которой вы должны понять несколько простых истин из будущего (которые я вкратце постарался осветить в данном видео):

  • Все «артефакты» Infrastructure as Сode, описывающие даже самые сложные инфраструктуры компаний — простые текстовые файлы, как и исходный код у девелоперов!

  • «Админы инфраструктуры» медленно переползают в «разработчиков инфраструктуры» (писателей ARM шаблонов и скриптов runbook на PowerShell)...

  • «Админы рабочих мест/серверов» в «разработчиков конфигураций» (писателей DSC и, снова же — скриптов PowerShell)...

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

  • И да поможет вам <тут фрагмент политкорректности> в вашем постижении новой мудрости и желании перерасти свой консерватизм с RDP и кликами next-next-next!!!

SysAdmin vs DevOps—что разного и что общего—будущее системных администраторов на примере автоматизации развертывания и конфигурирования VM в Azure—Infrastructure as Code и инструменты DevOps, которыми сисадмин должен будет владеть в ближайшем будущем

+55
голосов

Напечатать Отправить другу

Читайте также

За редким исключением ( Devops - это Linux), Microsoft теряет позиции практически по всем направлением, я уже не говорю про частные облака - Openstack обгоняет - (Microsoft) со своими продуктами под частные облака
Microsoft до сих пор не использует объектную сеть хранения.
Что касается продуктов для управления docker --- ( найдите сумасшедшего которые будет использовать Kubernetus или Openshift под Microsoft -- я честно таких не знаю.
Зачем Azure чего то там развертывать и управлять если есть Ansible, Pupet, Cheif.
Microsoft SQL - уже под Linux
Sharepoint и Exchange - ждем --
Когда Microsoft откажется от наследия древности IIS наверное вопрос времени. и перейдет на Nginx
Microsft идет по пути RedHat -- открытый код в своих продуктах, и покупка Github тому подтверждение.

Все это актуально или будет актуально для компаний с количеством персонала 50+
Для 99% более мелких компаний, уже имеющих "своего" сисадмина это неактуально и никогда не будет актуально.
Так-что никуда СисАдмины не исчезнут, просто сократиться немного поле вакансий.

 
 
IDC
Реклама

  •  Home  •  Рынок  •  ИТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Сети  •  Безопасность  •  Наука  •  IoT