Каждые несколько месяцев крупный сервис падает так, что вместе с ним ложится значительная часть интернета, и причина оказывается в слое, который все считали давно абстрагированным.
Абстракция скрывает слой, а не удаляет его
История, которую рассказывают об инфраструктуре последние пятнадцать лет, — что она исчезла в облаке. Серверы стали инстансами, потом контейнерами, потом функциями. Сети стали конфигурацией. Хранилище стало интерфейсом.
Каждый из этих шагов реален и полезен, и ни один из них ничего не убрал. Пакету по-прежнему нужно дойти до места назначения. Имени по-прежнему нужно разрешиться. Сертификату по-прежнему нужно быть действительным и актуальным. У диска по-прежнему есть ёмкость. Часам по-прежнему нужно совпадать с другими часами.
Изменилось то, кто замечает отказ одной из этих вещей и насколько трудно его увидеть.
Абстракция отодвигает отказ дальше от человека, который его испытывает, а значит, найти неисправность труднее, а человек, способный это сделать, — ценнее.
Это рабочий аргумент в пользу направления. Не ностальгия по установке серверов в стойку, а наблюдение: число людей, способных рассуждать о том, что реально происходит под капотом, снижалось быстрее, чем падала потребность в них.
Что охватывает направление
Область: операционные системы, оборудование, сети, серверы, администрирование и диагностика неисправностей.
Четыре области.
Сети. Адресация, маршрутизация, разрешение имён, балансировка нагрузки, межсетевые экраны и путь, который реально проходит запрос.
Операционные системы. Процессы, права доступа, файловые системы, службы и логи — на платформах, которые использует организация.
Идентификация и каталоги. Аутентификация, авторизация, сертификаты и системы, которые их выпускают.
Эксплуатация. Мониторинг, резервное копирование и восстановление, мощности, патчинг и структурированная диагностика неисправностей.
Всегда виноват DNS — и почему в этой шутке есть правда
Постоянная шутка среди инженеров инфраструктуры указывает на нечто реальное в том, как ломаются системы.
Разрешение имён лежит почти под всем, невидимо, пока работает, и порождает симптомы, которые выглядят совсем как другие проблемы. Приложение кажется медленным, когда разрешение работает с таймаутом. Сервис кажется упавшим, когда запись указывает на выведенный из эксплуатации адрес. Изменение распространяется неравномерно из-за кеширования на нескольких уровнях, так что система сломана для одних пользователей и в порядке для других, — а это самый трудный для диагностики паттерн отказа.
Три других члена той же семьи вызывают похожую долю инцидентов по той же причине.
Сертификаты. Они истекают. В дату, известную заранее за годы. Крупные сбои в больших организациях случались именно из-за этого, неоднократно, потому что продление было ручным, а человек, который об этом знал, уволился.
Время. Расхождение часов ломает протоколы аутентификации, делает недействительной проверку сертификатов, портит корреляцию логов и заставляет распределённые системы вести себя бессвязно. Проявляется это как проблема аутентификации, поэтому люди расследуют аутентификацию.
Маршрутизация и путь. Асимметричные маршруты, изменения пути, правила межсетевого экрана, добавленные для одной цели и затрагивающие другую. Симптомы проявляются периодически и только для части источников.
Их объединяет то, что каждое из этого — инфраструктура, от которой зависят все и которую никто не считает своей, и каждое даёт симптомы на слое, далёком от причины. Инженеры, знающие, что проверять в первую очередь, решают за минуты то, что иначе заняло бы день.
Где это находится в домене
ИТ-системы и компьютерные сети — седьмое из восьми направлений в домене ИИ, данных и вычислений Astra Trainer, и оно работает как снабженческая линия для остального. Облачные вычисления и DevOps, кибербезопасность и платформенная инженерия — все набирают людей отсюда, и все опираются на понимание, которое строит это направление.
Оно теснее всего связано с компьютерными науками — за моделью операционных систем и сетей, и с кибербезопасностью, где способность рассуждать о том, что система реально делает, — основа детектирования и реагирования. Восемь направлений можно посмотреть здесь.
Диагностика неисправностей — это метод, а не талант
Самая переносимая и наименее преподаваемая компетенция в этом направлении. К ней относятся как к тому, что у человека либо есть, либо нет, а на деле это процедура.
Установите, что реально изменилось. Системы, которые работали вчера и отказывают сегодня, обычно изменились, даже когда все говорят, что ничего не менялось. Деплои, продление сертификатов, обновления правил, истёкшие учётные данные, диск, пересёкший порог заполненности.
Точно определите масштаб. Все пользователи или часть. Все локации или одна. Постоянно или периодически. Каждый ответ исключает целые категории причин, и неточность здесь — причина того, что расследование блуждает.
Проверяйте вдоль пути. Запрос проходит известную последовательность компонентов. Тестируйте в точках вдоль неё и определите, где поведение перестаёт соответствовать ожиданиям. Это превращает открытую задачу в поиск с конечным ответом.
Меняйте по одной вещи за раз. Изменить несколько и обнаружить, что заработало, оставляет вас без понимания причины, а значит, вы не можете это предотвратить и не сможете исправить в следующий раз.
Читайте логи правильно. Не последнюю ошибку, которая часто является следствием, а первую аномалию и последовательность вокруг неё, сопоставляя время между системами.
Знайте, когда восстанавливать, а когда диагностировать. Во время сбоя часто правильнее восстановить сервис и расследовать потом. Путать восстановление с поиском первопричины — так и повторяется один и тот же инцидент.
Преподанное явно, это делает обычных инженеров заметно эффективнее. Оставленное неявным, люди осваивают это годами — или никогда.
Настоящая карьерная проблема этого направления
Стоит назвать прямо, потому что это реальное ограничение, и оно не техническое.
К работе с инфраструктурой относятся как к накладным расходам. В бюджетах она отражена как затраты, её измеряют отсутствием проблем, и замечают почти исключительно тогда, когда что-то ломается. Разработка строит вещи, о которых объявляют. Инфраструктура поддерживает вещи работающими, а это не порождает анонсов.
Отсюда четыре следствия.
Оплата и статус отстают от смежных ролей сопоставимой или меньшей сложности, что выталкивает способных людей из этой дисциплины.
Инвестиции приходят после инцидентов и сходят на нет после них, поэтому компетенция строится реактивно.
Аутсорсинг убрал площадку для обучения. Junior-позиции, на которых формировалось понимание инфраструктуры, во многих организациях отдали на подряд, — та же блокировка конвейера, что описана в статье про кибербезопасность.
Знание недокументировано и персонально. Какие системы важны, как выглядит норма, где странная зависимость. Оно уходит вместе с человеком, а замена медленно и дорого выстраивает его заново.
Организации, желающей получить компетенцию в облаке, безопасности и платформенной инженерии, стоит признать, что она сейчас недоинвестирует в ту популяцию, из которой эти дисциплины набирают людей, и что это решение можно дёшево изменить.
Роли, поимённо
Системные администраторы на основных платформах.
Сетевые инженеры и архитекторы.
Инженеры инфраструктуры.
Специалисты по идентификации и каталогам.
Инженеры хранилищ и резервного копирования, чья важность становится очевидна ровно один раз.
Специалисты по виртуализации.
Инженеры пользовательских устройств и конечных точек.
Служба поддержки и техническая поддержка — самая частая точка входа во весь домен.
Техники дата-центров — популяция, снова выросшая вместе с наращиванием вычислительных мощностей.
Кого можно обучить этому
Сотрудники службы поддержки. Классический и до сих пор лучший путь. Они уже видят всю инфраструктуру целиком, знают, что ломается, и обладают чутьём диагностики, которое структурированное обучение превращает в метод.
Техники телекоммуникаций. В сети, обладая знанием физического и транспортного уровня.
Военные связисты и специалисты по информационным системам. Часто превосходны, приходят с техническим навыком и операционной дисциплиной одновременно.
Электрики и техники инженерных систем зданий. В работу с дата-центрами и физической инфраструктурой.
Любой, кто неформально администрировал системы, в малом бизнесе или как человек, к которому обращаются все. Реальная компетенция без формального признания.
Разработчики. В инфраструктурные и платформенные роли, где им не хватает операционной половины, которую они никогда не получали.
Специалисты, меняющие карьеру, из операционных ролей в логистике, производстве или коммунальном хозяйстве, где дисциплина процесса и сменная работа переносятся напрямую.
Доступ, управление изменениями и обязательства по непрерывности. Административный доступ к продакшен-системам — это позиция с высокими привилегиями, регулируемая требованиями управления изменениями, логирования и разделения обязанностей, а в регулируемых отраслях — специфическими фреймворками контроля. Способность к резервному копированию и восстановлению во многих отраслях подчинена юридическим и контрактным обязательствам, а непроверенные резервные копии неоднократно подводили именно тогда, когда были нужны. Astra Trainer формирует техническую компетенцию и понимание того, где применяются эти обязанности. Это не даёт разрешения на доступ к какой-либо системе и не заменяет требования организационного контроля.
Что важно вынести
Облачные абстракции увели инфраструктуру за интерфейс, не убрав её, а это сделало неисправности труднее находить, а людей, способных их находить, — ценнее.
Разрешение имён, сертификаты, время и маршрутизация вызывают непропорционально большую долю сбоев, потому что невидимы, пока не откажут, и дают симптомы далеко от причины.
Диагностика неисправностей — это метод, которому можно научить, а не талант, и обучение ему явно — одно из самых окупаемых технических вмешательств.
Настоящее ограничение здесь — статус и приток кадров, а не спрос, а аутсорсинг убрал junior-позиции, где раньше формировалось это понимание.
И каждая команда облака, DevOps и безопасности набирает людей из этой популяции. Недоинвестировать сюда — значит недоинвестировать во все они.
Сделало ли облако навыки инфраструктуры ненужными?
Нет. Оно увело инфраструктуру за интерфейс. Сети, операционные системы, разрешение имён и хранилище по-прежнему существуют и по-прежнему выходят из строя, а абстракция отодвигает отказ дальше от симптома, что усложняет диагностику.
Почему DNS, сертификаты и время вызывают так много сбоев?
Потому что от них всё зависит, ими никто не владеет, они невидимы, пока работают, и их отказы дают симптомы на совершенно другом слое. В частности, истечение сертификатов неоднократно вызывало крупные сбои в даты, известные заранее за годы.
Можно ли научить диагностике неисправностей?
Да. Установите, что изменилось, точно определите масштаб, тестируйте вдоль пути запроса, меняйте по одной вещи за раз, читайте логи с первой аномалии, а не с последней ошибки, и отличайте восстановление сервиса от поиска первопричины.
Почему инфраструктуру недооценивают?
Потому что её измеряют отсутствием проблем и замечают только во время сбоев, поэтому в бюджетах она выглядит как затраты. Оплата и статус отстают от смежных ролей, инвестиции приходят реактивно после инцидентов, а аутсорсинг убрал junior-позиции, на которых формировался этот навык.
Кто хорошо конвертируется в роли инфраструктуры?
Сначала сотрудники службы поддержки, затем техники телекоммуникаций в сети, военные связисты, электрики в работу с дата-центрами, неформальные администраторы и разработчики, которым нужна операционная половина.