Системный администратор умер. Да здравствует системный администратор!

На протяжении десятилетий представление о системном администрировании (СА) менялось синхронно с изменениями в компьютерных системах. Как специальность, СА возникло стихийно, из необходимости каким-то образом справляться со сложностями первых операционных систем на мэйнфреймах.

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

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

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

В конце XX века из сисадминов-любителей выросли профессионалы

С 2000 года в США отмечается День благодарности со стороны пользователей системным администраторам (System Administrator Appreciation Day), он сопровождается угощением сисадминов тортами и мороженым. В Россию эта традиция пришла в 2006 году, но у нас это скорее собственный профессиональный праздник, собирающий на массовые мероприятия сисадминов в нескольких городах.

На этом благостном фоне поведение российских властей выглядит странным. В официальный «Перечень ФГОС СПО по ТОП 50 перспективных профессий Федеральных государственных образовательных стандартов среднего профессионального образования» наряду с сугубо рабочими специальностями включены «Администратор баз данных» и «Сетевой и системный администратор». Гид TAdviser по российским заводам компьютерной техники 14.8 т

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

Чему удивляться, не только охота и рыбалка, но и многое другое в России имеет национальную особенность. Особенность работы сисадмина в родной реальности прекрасно описана в состоящей из трех частей статье «Уйти или остаться? Закулисные проблемы сисадминов»^[1]. Имя автора – Лев Мышкин. Хотя скорее всего это псевдоним, непосредственным образом ассоциирующийся с князем Львом Николаевич Мышкиным — главным героем романа Федора Михайловича Достоевского «Идиот».

Еще особенности российского системного администрирования описаны в статьях «Семь принципов Наполеона для системных администраторов»^[2] и «Как стать системным администратором — пособие для начинающих»^[3].

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

Представление о системном администраторе в 2017 году

Обычно в сисадмине видят человека, отвечающего за поддержание в рабочем состоянии персональных, но чаще многопользовательских компьютеров – серверов. В его задачу входит обновление ресурсов, обеспечение требуемых уровней производительности и безопасности в рамках выделяемого бюджета. Сисадмины совместно с обслуживающими инженерами устанавливают и обновляют программное и аппаратное обеспечение, поддерживают правила обеспечения безопасности, обучают пользователей и технический персонал.

По области деятельности занятых в СА можно разделить на несколько категорий:

• Администраторы баз данных – поддерживают СУБД, отвечают за целость и производительность баз данных.
• Сетевые администраторы – поддерживают сетевые инфраструктуры (маршрутизаторы, коммутаторы) и подключение к ним компьютеров.
• Администраторы безопасности – специалисты в области информационной безопасности, которые обеспечивают работу защитных экранов и других устройств.
• Web-администраторы – поддерживают web-серверы (Apache или Internet Information Services), обеспечивающие доступ к внутренним и внешним сайтам, включая конфигурирование, безопасность и обновление.
• Администраторы серверов – осуществляют поддержку оборудования на физическом уровне (замена вышедших из строя устройств, замена лент и т.п.).
• Администраторы систем хранения данных (СХД) - поддерживают СХД, приложения, резервное копирование и установку новых устройств.

Что ждет системного администратора в будущем?

Со времен мэйнфреймов и практически до начала XXI века представление об ИТ страдали односторонностью. В ИТ и людях, которые их поддерживают, видели исключительно средства, способные выполнять те или иные функции, не более того.

Сравним с традиционными производствами. Там есть люди, которые обеспечивают процесс производства (работу конвейеров, роботов и т.д.), есть специалисты, использующие технологии для изготовления требуемого продукта, а есть те, кто используют созданный продукт. В ИТ первые – это системные администраторы, а кто отвечает за результаты, остается неопределенным.

Но ситуация меняется, и постепенно в ИТ складывается примерно такая же трехзвенная система, которая существует повсюду. Основным продуктом ИТ признаны данные. На третьем уровне данные используют аналитики, так называемые data scientist, с ними все более или менее ясно. А что же происходит с первым и вторым звеньями? Традиционные задачи, перечисленные выше, с сисадминов никто не снимает, зато появляются новые, и они связаны с новыми направлениями - Data governance и DevOps.

Руководство данными

Data governance точнее всего перевести как «руководство данными». Не управление, а именно руководство. Под Data governance понимают комплекс мер, направленных на сохранение и поддерживание качества данных как важного актива предприятия.

Роль Data governance в корпоративной стратегии компании отмечают системные интеграторы^[4]:

С появлением ИТ-архитектуры, в центре которой находятся потоки бизнес-данных, возникла новая бизнес-задача, которой раньше в принципе не существовало. Это обеспечение организационного процесса управления корпоративными данными (Data Governance). Решение этой задачи подразумевает создание специальной организационной единицы, которая занимается управлением данными как активом организации. Это большой сложный вопрос: каким образом методологически управлять жизненным циклом данных, каким образом поддерживать корпоративную модель данных. Без такой модели, без понимания, какие данные есть в организации, как ими управлять и как они могут быть использованы бизнесом, данные не представляют никакой ценности. В большинстве компаний этот вопрос пока никак не решается, хотя в западных компаниях есть примеры отношения к данным как к важнейшему корпоративному активу

В связи с этим в штате СА появятся новые специальности:

• Администратор данных (Data admin) Менеджер ресурсов данных мониторит корпоративные данные, обеспечивает управление ими как активом, управляет жизненным циклом данных в соответствие с целями и задачами предприятия. Такого рода менеджмент основывается на логических моделях данных и их потоков. Администратор данных отличается от администратора баз данных тем, что первый работает с данными на логическом уровне, а второй на физическом.
• Хранитель данных (Data custodian) играет центральную роль в команде, руководящей данными, он отвечает за их агрегирование и использование, он функционально ближе к администратору баз данных с учетом того, что данные, с которыми он имеет дело, разнообразнее.
• Управляющий данными (Data steward) планирует работу с данными, анализирует источники, связывает элементы данных с метаданными.

DevOps и системное администрирование

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

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

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

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

О будущем разделении труда между программистами и администраторами еще в 1947 году писал Алан Тьюринг:

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

Пророчество Тьюринга во многом оправдалось, за прошедшее с тех пор время история разработчиков (Dev) и операторов (Ops) успела совершить несколько витков развития. На первых порах, еще до появления мэйнфреймов, разделения между разработчиками и операторами не было — тогда были программисты и инженеры, сохранявшие работоспособность крайне ненадежных систем.

Мэйнфреймы с их пакетным режимом разделили программистов и операторов — первые отдавали колоды перфокарт со своими программами, а операторы запускали их на счет и возвращали листинги.

Возврат на исходную позицию (объединение программиста и оператора в одном лице) случился в семидесятые годы с появлением мини-ЭВМ и диалогового режима — посредники-операторы здесь не требовались, и исчез барьер между разработчиком и компьютером.

Но с появлением персональных компьютеров и локальных сетей, клиент-серверных архитектур и баз данных инфраструктура заметно усложнилась и снова возникло деление на Dev и Ops. В последующем появились крупные ЦОДы и самостоятельные ИТ-подразделения, целиком состоящие из Ops, — снова возник барьер между двумя сторонами.

В XXI веке сложилось строгое разделение труда между Dev и Ops. Задачи первых свелись к созданию нового ПО и его периодическим обновлениям, а вторых — к обеспечению пользователям надежного и быстрого доступа к системным ресурсам. Но при том что и Dev, и Ops делают общее дело, их интересы совпадают лишь частично. Естественно, что программисты не хотят делать ПО с ошибками, а люди из ИТ — обрушивать его в процессе эксплуатации, в этом они едины, и пока требования к скорости появления новых релизов ПО были относительно невелики, между ними не было серьезных противоречий.

Если бы потребности пользователей ограничивались только готовым покупным тиражируемым ПО, то разделение, предсказанное Тьюрингом, сохранилось бы еще надолго, но возникли два новых явления: непрерывное обновление ПО (Continuous Delivery, CD) и непрерывная интеграция (Continuous Integration, CI).

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

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

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

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

Примечания