Миф: в облаке администратор не нужен

MAATRIX

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

Что в этом мифе правда

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

• Физическое обслуживание железа исчезает полностью. Не нужно ехать в дата-центр менять вышедший из строя диск, следить за температурой в серверной, договариваться о замене блока питания. Это буквально не ваша забота — за неё отвечает провайдер, и это реальная, ощутимая экономия часов.
• Базовый патчинг ОС в managed-сервисах провайдер берёт на себя. Если вы используете managed-базу данных или managed-Kubernetes, вам не нужно вручную накатывать патчи ядра или обновлять минорную версию СУБД — это часть услуги.
• Резервирование на уровне инфраструктуры становится проще запросить. Реплики, снапшоты, географическое распределение — доступны как настройка в панели, а не как отдельный проект на месяц.
• Порог входа для запуска нового сервиса ниже. Поднять новую базу или очередь можно за несколько минут кликами, не разворачивая её вручную и не подбирая конфиг с нуля.

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

Что появляется взамен: IAM и управление правами доступа

На собственном сервере вопрос «кто может зайти» решается относительно просто: SSH-ключи, sudo, может быть LDAP для команды побольше. В облаке эта задача не исчезает — она превращается в отдельную дисциплину под названием IAM (Identity and Access Management), и по сложности она обычно даже превосходит то, что было на голом железе.

Причина в том, что в облаке появляется не один периметр, а десятки пересекающихся: доступ к консоли управления, доступ к API, роли для сервисных аккаунтов, политики для отдельных ресурсов (бакет, база, очередь, функция), временные ключи для CI/CD. Каждый из них — отдельная поверхность для ошибки. Типичная картина в компании через год после переезда в облако:

• один и тот же сервисный аккаунт CI/CD имеет права администратора на весь проект, потому что «так было проще один раз настроить и все забыли вернуться»;
• у уволившегося три месяца назад подрядчика до сих пор активен долгоживущий ключ доступа;
• хранилище с бэкапами открыто на чтение шире, чем нужно, потому что при создании поставили «публичный доступ», чтобы быстро скачать файл, и забыли закрыть обратно;
• в консоли управления есть пять человек с правом удалять ресурсы, хотя реально это нужно одному.

Ничего из этого не настраивается «само». Наоборот, грамотная модель доступа в облаке требует больше дисциплины, чем chmod и список пользователей в /etc/passwd: нужно проектировать роли по принципу минимально необходимых привилегий, регулярно проводить ревизию прав, ротировать ключи, включать логирование обращений к API и реально его читать. Тот, кто это делает, — по сути тот же администратор, только теперь его инструмент не usermod, а политики доступа и роли в облачной консоли.

Cost management: новая работа, которой раньше просто не было

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

Практика показывает несколько повторяющихся сценариев перерасхода:

• Забытые ресурсы. Тестовое окружение подняли для одной задачи и не выключили — оно тихо капает в счёт месяцами.
• Неверный размер инстанса. Ресурс подобрали «с запасом на будущее» и не пересматривали, хотя реальная нагрузка выросла не так, как планировали.
• Плата за простаивающие мощности. В облаке нередко продолжают выставлять счёт за зарезервированные, но не работающие в моменте ресурсы — это отдельно разобрано в статье про то, почему в облаке платят за выключенный сервер.
• Трафик и операции ввода-вывода как скрытая статья расходов. Исходящий трафик и количество операций к хранилищу часто тарифицируются отдельно от самого хранения, и именно эта строчка чаще всего становится сюрпризом в конце месяца.

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

Сетевая архитектура облака не строится по умолчанию

На выделенном сервере сетевая настройка обычно сводится к файрволу и, возможно, VPN между несколькими машинами. В облаке сеть — это отдельный слой абстракции со своей логикой: виртуальные приватные сети, подсети, таблицы маршрутизации, группы безопасности (security groups) на уровне отдельных ресурсов, правила для входящего и исходящего трафика между сервисами внутри одного облака и наружу.

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

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

Ошибка в этом слое не проявляется мгновенно — сервис будет работать, пока кто-то не просканирует открытые порты снаружи или пока не придёт неожиданный счёт за трафик через неправильно выбранный маршрут. Это тот случай, когда сложность неверно настроенного облака создаёт риски безопасности ничуть не меньшие, чем плохо администрируемый собственный сервер с открытым портом 22 и паролем по умолчанию — миф про облачную безопасность «из коробки» разобран отдельно в статье про то, что своя защита не гарантирует безопасность сама по себе.

Мониторинг зоопарка managed-сервисов

Ещё один аргумент в пользу мифа звучит так: «managed-сервис сам следит за своим здоровьем, зачем его мониторить». Отчасти это верно — провайдер действительно отслеживает базовые метрики железа под сервисом и обычно быстро реагирует на аппаратные сбои. Но это не то же самое, что мониторинг вашего конкретного использования сервиса.

Managed PostgreSQL не подскажет вам, что в вашем приложении появился медленный запрос без индекса, который постепенно съедает всё больше времени соединения. Managed-очередь сообщений не пришлёт алерт, если у вас начал расти backlog необработанных сообщений из-за упавшего воркера — с точки зрения провайдера сама очередь работает штатно. А чем больше отдельных managed-сервисов используется одновременно — база, очередь, объектное хранилище, функции, кеш, — тем больше точек, за которыми нужно следить именно с прикладной, а не с инфраструктурной стороны.

На практике команда, переехавшая в облако с расчётом «мониторинг теперь не нужен», обычно приходит к следующему:

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

Роль администратора смещается, а не исчезает

Если сложить всё сказанное выше, картина получается предсказуемая: физического администрирования железа в облаке действительно меньше или нет совсем, а базовый патчинг managed-сервисов провайдер берёт на себя. Но одновременно появляются задачи, которых на выделенном сервере не было в таком объёме: проектирование IAM-политик, постоянный контроль затрат, сетевая архитектура на уровне облачных абстракций, мониторинг множества разнородных managed-сервисов. Смысл не в том, что работы стало меньше, а в том, что она сменила форму.

Разница хорошо видна в сравнении:

Именно поэтому компании, которые переезжают в облако и одновременно сокращают штат инженеров инфраструктуры «потому что теперь всё само», регулярно наступают на одни и те же грабли: открытые бакеты, забытые ресурсы, счета, которые растут без видимой причины, инциденты, которые никто не заметил вовремя, потому что мониторинг остался на уровне «сервис отвечает на пинг». По сути это тот же набор рисков, что и у плохо администрируемого выделенного сервера, — просто он спрятан за красивой панелью управления и ощущением, что «облако само разберётся». Хорошее сравнение того, как быстро и по каким причинам растёт цена облака относительно выделенного сервера, — в статье «Где облако становится дороже VPS».

Если в компании нет своей инженерной экспертизы и весь расчёт строится на «managed-сервисы обо всём позаботятся», разумнее сразу оценить границы этого решения — подробный разбор того, что реально закрывает managed-услуга, а что всё равно остаётся на стороне клиента, есть в статье «Своя DevOps-экспертиза против managed-услуг».

Частые вопросы