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


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

NoDevOpsПотому, в данной презентации со Стального Бубна 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 используют (или они берутся сами за работу) не по прямому назначению – как архитекторы и администраторы ИТ-инфраструктуры обычной компании с ее обычными сервисами + немного облаков.


Steel Drum/Стальной Бубен – доклад по реализации проектов Azure Site Recovery или DevOps vs SysAdmin

Также смотрите и читайте другие материалы для ИТ-профессионалов у меня на канале iWalker2000 и блоге:

 

Итак, вернемся к отзывам обычных компаний про место 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, а уже опубликованные серии, где рассматривается применение Azure со стороны системных администраторов, найдете здесь – https://youtu.be/MEjC_GityKc


Steel Drum/Стальной Бубен – Infrastructure as Code – автоматизация развертывания VM в Azure 

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

  • Все «артефакты» Infrastructure as Сode, описывающие даже самые сложные инфраструктуры компаний – простые текстовые файлы, как и исходный код у девелоперов!
  • «Админы инфраструктуры» медленно переползают в «разработчиков инфраструктуры» (писателей ARM шаблонов и скриптов runbook на PowerShell)…
  • «Админы рабочих мест/серверов» в «разработчиков конфигураций» (писателей DSC и, снова же – скриптов PowerShell)…
  • Инфраструктурный и конфигурационный код может быть сохранен, версионизирован, протестирован и распространен, как и программный код – у вашей инфраструктуры вскоре появятся свои сборки, свои релизы, и свои тестовые и разрабатываемые копии в отдельных «слотах».
  • И да поможет вам <тут фрагмент политкорректности> в вашем постижении новой мудрости и желании перерасти свой консерватизм с RDP и кликами next-next-next!!!

Это не единственный семинар, который я читал в Украине, в ближайшее время еще одно интересное мероприятие для сисадминов пройдет в Харькове, 13 июня 2018 всех интересующихся приглашаю сюда – SysAdmin Day.Kharkiv 2018 – https://www.facebook.com/SysAdminDayUA/ (предварительная регистрация обязательна). И, конечно же, следите за выпусками технических видео на канале – http://bit.ly/WindowsServer_overview .

 

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

 

Видео об ИТ-карьере – как стать ИТ-специалистом и заработать много денег:

Немного ссылок на другие материалы для тех, кто хочет стать просто ИТ-специалистом – смотрите первые шаги по созданию тестового рабочего места:

И смотрите другие видео для ИТ-специалистов у меня на канале:

Видео про новые возможности дисков и дисковых массивов:

 

Подписывайтесь на мой Youtube канал iWalker2000 – для подписки просто кликните сюда

 

Также, по просьбам посетителей – меня найти можно (добавляйтесь в друзья и подписчики):

 

Эмиграция для ИТ-профессионалов в Европу! Оформление ВНЖ в Словакии, возможность работы со всеми странами ЕС, открытие фирм, ЧП с соответствующими видами деятельности, оформление документов для членов семьи. Быстро, качественно, дешево и абсолютно легально ВНЖ в Словакии. www.slovakiago.com
Не упустите свой шанс жить и работать в Евросоюзе!

Advertisements

Залишити відповідь

Заповніть поля нижче або авторизуйтесь клікнувши по іконці

Лого WordPress.com

Ви коментуєте, використовуючи свій обліковий запис WordPress.com. Log Out /  Змінити )

Google+ photo

Ви коментуєте, використовуючи свій обліковий запис Google+. Log Out /  Змінити )

Twitter picture

Ви коментуєте, використовуючи свій обліковий запис Twitter. Log Out /  Змінити )

Facebook photo

Ви коментуєте, використовуючи свій обліковий запис Facebook. Log Out /  Змінити )

w

З’єднання з %s