Как проверить работу админа, если сами вы в серверах не разбираетесь

MAATRIX

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

Почему «на глаз» это не оценить — и это нормально

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

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

Дальше — по каждому из этих маркеров: что именно проверять, какие вопросы задавать и какие ответы должны насторожить.

Регулярность и содержательность отчётов

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

На что смотреть:

• Регулярность. Отчёт приходит по расписанию — раз в месяц, раз в две недели — а не тогда, когда вы сами вспомнили спросить. Если единственный способ узнать, что происходит с сервером, — написать администратору лично и подождать ответа, отчётности как процесса у вас нет.
• Содержательность vs шаблонность. Отчёт меняется от месяца к месяцу и отражает реальные события: «обновили PostgreSQL до новой версии, простоя не было», «заметили рост нагрузки на диск, разобрались — виноваты старые логи, почистили и настроили ротацию». Если из месяца в месяц приходит одна и та же фраза «всё в порядке, проблем нет» без единой конкретной детали — это тревожный признак: либо отчёт никто не читает и его не для чего наполнять содержанием, либо администратор сам не фиксирует, что делает.
• Понятный язык. Хороший отчёт написан так, что вы, не зная терминов, понимаете суть: что случилось, насколько это было серьёзно, что сделано. Отчёт, состоящий из сплошного технического жаргона без единого поясняющего предложения — это не признак глубины, а часто признак того, что автору лень (или нечем) объяснять по-человечески.

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

Документация: не важно понять содержание, важен факт её существования

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

Спросите прямо: «Где документация по нашим серверам? Пришлите ссылку или файл». Дальше оценивайте не техническое содержание, а формальные признаки:

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

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

Реакция на инциденты: скорость и качество коммуникации

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

Оценивайте по трём осям:

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

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

Готовность объяснять решения простым языком

Четвёртый индикатор — возможно, самый недооценённый: попросите администратора объяснить любое непонятное вам решение обычными словами, и посмотрите на реакцию.

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

Обратная ситуация — тревожный сигнал сам по себе. Если в ответ на «а зачем нам это нужно, объясните по-простому» вы регулярно получаете:

• поток терминов без единой попытки перевести их на бытовой язык;
• раздражение или снисходительное «вы всё равно не поймёте»;
• уклончивое «долго объяснять, просто доверьтесь»;

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

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

Независимый аудит: не недоверие, а разумная практика

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

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

• Насколько безопасно настроены доступы и сеть?
• Соответствует ли объём ресурсов реальной нагрузке, или вы годами переплачиваете за мощности, которые никто не использует?
• Есть ли работающие резервные копии, и проверялось ли когда-нибудь их реальное восстановление?
• Насколько инфраструктура вообще соответствует тому, что описано в документации и отчётах?

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

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

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

Токсичный паттерн: доверие без единого проверочного механизма

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

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

Признаки, что вы уже в этом паттерне:

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

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

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