company_banner

Почему системные администраторы должны становиться DevOps-инженерами

Автор оригинала: Taz Brown (Red Hat)
  • Перевод

Для обучения в жизни нет лучшего времени, чем сегодня.

На дворе 2019 год, и тема DevOps сейчас актуальна, как никогда. Говорят, что дни системных администраторов прошли, как миновала эпоха мейнфреймов. Но так ли это на самом деле?
Как это часто бывает в IT, ситуация изменилась. Появилась методология DevOps, но она не может существовать без человека с навыками системного администратора, то есть без Ops.

До того как DevOps-подход приобрёл свой современный облик, я относил себя к категории Ops. И я хорошо знаю, что испытывает сисадмин, когда понимает, сколько же всего он пока не умеет и как мало времени у него на то, чтобы этому научиться.



Но действительно ли всё так страшно? Я бы сказал, что не нужно воспринимать недостаток знаний как какую-то большую проблему. Это скорее профессиональный вызов.

Web-scale-продукты основаны на Linux или другом программном обеспечении с открытым исходным кодом, а на рынке можно найти всё меньше специалистов, способных их обслуживать. Спрос уже превысил количество профессионалов в этой области. У системного администратора уже не получится просто продолжать работать, не повышая свой уровень квалификации. Он должен иметь навыки автоматизации, чтобы управлять множеством серверов/узлов, и хорошо понимать принципы их работы, чтобы решать возникающие проблемы.

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

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

В первую очередь важно понять, что DevOps — это не конкретная должность в компании, а набор определённых практик. Эти практики подразумевают распределение изолированных систем, снижение вреда от багов и ошибок, частое и своевременное обновление ПО, налаженное взаимодействие между разработчиками (Dev) и администраторами (Ops), а также постоянное тестирование не только кода, но и всей структуры в рамках процесса непрерывной интеграции и доставки (CI/CD).

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

Чего вам может не хватать как специалисту по Ops, так это навыков программирования. Сейчас написание сценариев (скриптов), которыми системные администраторы пользуются для автоматизированной установки патчей на сервере, управления файлами и учётными записями, для устранения неполадок и составления документации, уже считается устаревшим. В относительно простых случаях сценарии по-прежнему применяются, но концепция DevOps подразумевает решение крупномасштабных задач, будь то внедрение, тестирование, работа со сборками или развёртывание.

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

Что делать? Чтобы оставаться востребованным специалистом, нужно приобрести актуальные навыки — освоить как минимум один язык программирования, например Python. Человеку, который профессионально занимается администрированием, это может показаться сложным, поскольку он привык думать, что программируют только разработчики. Совсем необязательно становиться экспертом, однако знание одного из языков программирования (это может быть Python, Bash или даже Powershell), безусловно, станет преимуществом.

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

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

Но насколько верно это утверждение?

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


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

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

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

Он также будет отвечать за обновление аппаратного обеспечения, проверку и анализ журналов, аудит безопасности, установку патчей на сервере, устранение неполадок, анализ первопричин и автоматизацию — как правило, посредством сценариев PowerShell, Python или Bash. Один из примеров использования сценариев — это управление учётными записями пользователей и групп. Создание учётных записей пользователей и назначение разрешений — задача чрезвычайно утомительная, поскольку пользователи появляются и исчезают почти каждый день. Автоматизация посредством сценариев позволяет высвободить время для решения более важных инфраструктурных задач, например для обновления коммутаторов и серверов и выполнения других проектов, влияющих на прибыльность компании, в которой администратор работает (хотя и принято считать, что IT-отдел не приносит доход напрямую).

Задача системного администратора — не тратить время впустую и экономить деньги компании любыми возможными способами. Иногда системные администраторы работают как члены большой команды, объединяющей, к примеру, администраторов Linux, Windows, баз данных, хранилищ и так далее. Рабочий график тоже бывает разным. Например, смена в одной временной зоне в конце дня передаёт дела следующей смене в другой временной зоне, чтобы процессы не останавливались (follow-the-sun); или у сотрудников обычный рабочий день с 9 утра до 5 вечера; или же это работа в круглосуточном дата-центре.

Системные администраторы со временем научились мыслить стратегически и сочетать важные дела с рутинными задачами. У команд и отделов, в которых они работают, обычно не хватает ресурсов, но при этом все стараются выполнять ежедневные задачи в полном объёме.

DevOps: разработка и обслуживание едины


DevOps — это своего рода философия процессов разработки и обслуживания. Такой подход в мире IT стал поистине новаторским.

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

В основе DevOps — контроль за разработкой и функционированием ПО на протяжении всего жизненного цикла. Специалисты по обслуживанию должны поддерживать разработчиков, а перед разработчиками стоит задача разбираться не только в API, используемых в системах. Они должны понимать, что находится «под капотом» (то есть как функционирует аппаратное обеспечение и операционные системы), чтобы лучше справляться с ошибками, решать проблемы и взаимодействовать со специалистами по обслуживанию.

Системные администраторы могут перейти в команду DevOps, если они хотят изучать новейшие технологии и открыты для инновационных идей и решений. Как я уже говорил, им необязательно становиться полноценными программистами, но освоение языков программирования, таких как Ruby, Python или Go, поможет им стать очень полезными членами команды. Хотя системные администраторы традиционно выполняют всю работу самостоятельно и часто воспринимаются как одиночки, в DevOps их ждёт совершенно противоположный опыт, когда все участники процесса взаимодействуют друг с другом.

Тема автоматизации становится всё более актуальной. Как системные администраторы, так и специалисты DevOps заинтересованы в оперативном масштабировании, снижении количества ошибок, а также в быстром поиске и устранении существующих ошибок. Таким образом, автоматизация — это понятие, где две области сходятся. Системные администраторы отвечают за такие облачные сервисы, как AWS, Azure и Google Cloud Platform. Они должны понимать принципы непрерывной интеграции и доставки и то, как использовать в работе инструменты типа Jenkins.

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

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

И последняя деталь в этом механизме — это Git. Работа с Git — одна из традиционных каждодневных обязанностей системного администратора. Эта система управления версиями широко используется разработчиками, специалистами DevOps, Аgile-командами и многими другими. Если ваша работа связана с жизненным циклом ПО, то совершенно точно вы будете работать с Git.

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

Если вы системный администратор, то вам нужно лучше изучить Git, понять, как строится управление версиями и запомнить распространённые команды: git status, git commit -m, git add, git pull, git push, git rebase, git branch, git diff и другие. Существует множество онлайн-курсов и книг, которые помогут изучить эту тему с нуля и стать профессионалом с конкретными навыками. Есть также замечательные шпаргалки с командами Git, поэтому зубрить их все необязательно, но чем больше вы пользуетесь Git, тем проще вам будет.

Заключение


В конечном счёте вы сами решаете, нужно ли вам становиться специалистом DevOps или лучше остаться системным администратором. Как видите, для перехода требуется обучение, но чем раньше вы начнёте, тем лучше. Выберите язык программирования и параллельно изучайте такие инструменты, как Git (контроль версий), Jenkins (CI/CD, непрерывная интеграция) и Ansible (конфигурирование и автоматизация). На каком бы варианте вы ни остановились, не забывайте, что нужно постоянно учиться и совершенствовать свои навыки.
FunCorp
266,98
Разработка развлекательных сервисов
Поделиться публикацией

Похожие публикации

Комментарии 23

    +2

    Я сильно ошибусь если предложу формулировку "Хотите больше денег приносите больше пользы"?

      +3

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

        +4
        Тоже страдал из-за этого, переехал — не жалею, чего и вам желаю)
          0
          Если есть возможность, то лучше переехать, пока есть бодрость духа и тела для построения карьеры.
          Если нет возможности, то можно попробовать удаленную работу найти.
            +1
            Но ведь есть и варианты удаленной работы в качестве DevOps-инженеров. У нас, например, работают люди из многих регионов.
              0
              В тоже время, имея неплохой опыт работы с Linux, но по стечению обстоятельств не имея необходимости поддерживать большие кластеры Kubernetes и соответственно не добавляя эту строчку в резюме — найти что то сложно. Обычно уже на уровне рассмотрения резюме HR отказывает.
                0
                Не скажу за других, но мы, занимаясь как раз-таки обслуживанием Kubernetes, наличие такого опыта не считаем обязательным. Главное — это всё же хорошая база, общие навыки/качества для того, чтобы погрузиться в нужное.
                  0
                  Оффтоп конечно, но самое забавное, что в первую очередь я отправлял резюме именно в компанию где Вы работаете. Видимо не подошел по каким то другим критериям.
                0

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

                0
                DevOpsом можно стать просто автоматизировав, закатав в Ansible, Jenkins, GIT и проч что описано в статье по фэн шую.
                Название вакансии также не всегда отражает суть. Я Linux Sysadmin, а по сути DevOps, индусы все сплошь и рядом «experts», «aws automation engineer», «DevOps», но реально уровень сисадминов Windows.
                  0
                  многие компании предлагают помощь с переездом
                  +3
                  Системный администратор это все-таки далеко не только администратор в компании где что-то разрабатывается… И потому остается открытым вопрос, зачем системному администратору какого-нибудь комитета образования или торговой компании практики DevOps?
                  Так же не уделено внимание и такому вопросу как DevOps трансформация всей компании. Практики DevOps ради практик ни к чему хорошему не приведут
                    0
                    Почему системные администраторы должны становиться DevOps-инженерами

                    • ЗП больше
                    • технологии интереснее
                    • нуждающиеся в них компании богаче (т.е. больше бенефитов кроме ЗП)
                    • супер простая релокация (предложения при открытом резюме стабильно раз-два в месяц)


                    Можно выбирать себе технологии самому, мотивируя это непригодностью к девопс практикам. Например я не люблю нагиос и забикс, и говорю что мы будем использовать современные средства, которые укладываются в девопс практики из тех что я люблю (Grafana, ELK, Prometheus).
                      0
                      предложения при открытом резюме стабильно раз-два в месяц

                      У меня 15 приглашений за неделю, только успевай как ниндзя отбиваться и собеседоваться. Это я не в активном поиске.

                        0
                        Ну да, я еще и шифруюсь, прячусь, но в базах уже есть у HR.
                        У тебя тоже стабильно раз в месяц от разных офисов EPAM приходят? :)
                      0
                      Приведут ради строчки в резюме, набора опыта, перепрыгивания в другую компанию на позицию повыше
                      +2
                      Прошу прощения, престал читать с момента упоминания обслуживания принтеров и оргтехники. О каком DevOps может идти речь если специалист по оптимизации процессов производства ПО отвлекается на работу эникея. В крайних двух компаниях что я работал были отделы DevOps, не просто один сотрудник а несколько, которые обслуживали среды тестирования и автоматизировали развертывание тестовых сред в облаках. Даже чтобы залезть под капот условному OpenStack, уже шла работа совместно с админами. А уж если ломается клавиатура, по заявке приходит эникей и её меняет. Такие роли как DevOps, SRE, даже админы 2,3,4 уровней поддержки появляются в компаниях соответствующего размера, где эти уровни поддержки вырисовываются сами от размера инфраструктуры. Если вы и жнец и на дуде игрец в маленькой компании, можно называть себя как угодно, от этого знаний как работать в больших инфраструктурах и взаимодействовать с соседними отделами (сетевиками, DBA, разработчиками) не появится, а это очень важная часть работы, не брать на себя все сразу, а концентрироваться на чем то одном и работать в команде с остальными.

                      Сейчас написание сценариев (скриптов),… уже считается устаревшим

                      и далее вы называете языками программирования Bash и PowerShell, которые и являются языками написания сценариев (скриптов). По личному опыту, мой питон пока не пригодился ни разу, Bash и PowerShell перекрывают 99% потребностей в автоматизации, ибо Docker, ибо облака в которых свои инструменты для всего. Я все еще читаю книжку по питону, потому что «надо», но это скорее для галочки в резюме.
                        –1

                        Читаю и странное ощущение. А был ли я когда-то админом?

                          0
                          Чем больше статей по DevOps попадается на глаза, тем больше ощущение, что данная специализация — попытка запихнуть ещё больший функционал в сущность системного администратора.
                          И если это так, то у меня дилемма: является ли появление DevOps последствием упрощением администрирования (имеется ввиду появление программных продуктов, позволяющих гибко автоматизировать накатывание конфигураций, развёртывание сред и всё прочее — настроил и забыл) или же консервативным стремлением сохранить должность человека-оркестра в корпоративных масштабах?

                          Так же на ум приходит выражение: «DevOps — это очень опытный эникей.» Разумеется, крайне утрированное.
                            0
                            [sarcasm] Расскажите, как с помощью devops можно администрировать виндовый файл-сервер, если в компании работает всего 90 человек? [/sarcasm]
                              0
                              Администратор — администрирует приложения.
                              DevOps — нянька для программистов.
                              Безусловно — владеть технологиями нужно, знать и уметь ими оперировать — нужно.
                              Но по моему субъективному мнению: Программист? Вот тебе GIT, вот тебе gitlab, вот тебе все инструменты. Да, какие то базовые вещи сделаю, но свой стэк разработки сопровождай сам.
                              У меня программисты не избалованы, нянек и седелок у них нет :) Само собой, мы им помогаем, администрируем с системной стороны их стек. Но релизят, деплоят, заводят репосы и разгребают траблы после своих деплоев, откатывая версии релизов — они сами.
                                0
                                роли devops раскиданы между администраторами и разработчиками. это нормально.
                                  0

                                  Соглашусь.
                                  У нас на проекте сейчас 3 девопса.
                                  Из них только у меня сисадминский бекграунд.
                                  Раскидали таски таким образом чтобы тспользовать больше сильные стороны каждого.
                                  И живём.
                                  На прошлой работе ситуация была похожаяя, только было два экс-сисадмина.

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

                              Самое читаемое