Зачем вообще писать про аутсорсинг
Все IT-кейсы, которые пишут в интернете — про «мы сделали классный продукт». Аутсорсинг — это не продукт. Это долгая, скучная, стабильная работа, в которой хороший результат выглядит как «у клиента ничего не сломалось». И эта «ничегонесломавшность» — наш главный результат за последние десять лет.
«Консоль» начинала именно как IT-аутсорсер. Петрозаводск, начало 2010-х, малому и среднему бизнесу нужен IT-специалист, но штатного позволить себе они не могут. Мы предложили модель «один договор — все IT-вопросы»: серверы, сети, рабочие станции, мониторинг, безопасность, 1С, всё. За десять лет через нас прошли десятки компаний, многие клиенты — до сих пор с нами. Среди них — Онегомед, ТК «Русский Север», ООО «Стоун» (сайт которому мы, кстати, в 2026 году переделали).
Challenge: в чём сложность регионального аутсорсинга
Первая иллюзия, которую я встретил в начале: «IT-аутсорсинг — это как сисадмин, только по договору». Нет. Это принципиально другая модель.
Штатный сисадмин знает свою инфраструктуру. У него в голове все пароли, костыли, конфиги и «не трогай этот провод, иначе сервер упадёт». Когда он уходит — компания теряет память.
Аутсорсер обязан иметь документированную инфраструктуру по каждому клиенту. Если один инженер заболел — другой должен войти, открыть runbook и починить. Это означает: wiki, схемы сети, список доступов в защищённом хранилище, runbook на все типовые инциденты, мониторинг, который шлёт алерт не одному человеку, а в дежурку.
Вторая сложность — SLA на малом бизнесе. Держать uptime 99.5% в регионе, где интернет-провайдер иногда падает просто потому, что суббота, — это отдельное искусство. Нужна резервная связь, нужны offline-сценарии работы 1С, нужно резервное копирование, которое работает без участия клиента.
Третья — экономика. Малый бизнес платит не как «Газпром». Модель должна быть одновременно доступной для клиента (реалистичный ежемесячный платёж) и прибыльной для нас. Это не получается, если на каждого клиента сажать отдельного инженера. Это получается, если инженеры работают на пуле клиентов, с типовыми процессами, с автоматизацией рутины.
Solution: как у нас это устроено
Пул инженеров на пул клиентов. У нас нет «сисадмина Васи, который знает твою компанию». У нас есть команда, у которой есть общая документация по всем клиентам. Заявка приходит — её берёт свободный инженер, делает, закрывает. Для клиента это выглядит как «всегда кто-то отвечает».
Мониторинг и алерты — в центр. По каждому клиенту на наших серверах стоят чекалки: серверы живы, диски не забиты, бэкап прошёл, RAID не посыпался, сайт отвечает, 1С-сервер жив, антивирус обновлён, электричество есть. Алерт падает не на почту (её никто не читает), а в Telegram в дежурный чат. Критичные алерты дублируются SMS ответственному инженеру.
Runbooks вместо героизма. Любой инцидент, который случился один раз, превращается в runbook. Это скучная работа, но именно она даёт стабильность. Когда в три часа ночи падает 1С у клиента, инженеру не нужно думать — он открывает runbook, идёт по шагам, чинит. Героизма нет — есть процедура.
Бэкапы — отдельная религия. Мы живём по правилу 3-2-1: три копии, на двух разных носителях, одна — вне офиса клиента. Проверяем восстановление раз в квартал на каждом клиенте. Не «проверяем, что бэкап создался», а именно восстановление на тестовом стенде. Это единственный способ узнать, что бэкап работает.
Безопасность. Антивирусы, фаерволы, сегментация сети, политики паролей, обучение сотрудников (да, приходится объяснять, почему не надо открывать «счёт на оплату.exe»). Последние пару лет — постоянный мониторинг утечек по базам слитых паролей, если email клиента всплывает — меняем доступы не дожидаясь инцидента.
А теперь про то, где тут AI
Можно было бы вставить AI для хайпа, но я честно расскажу, где он у нас реально работает, а где нет.
Работает:
-
Классификация тикетов. Заявки от клиентов приходят в произвольной форме — «у нас не печатает», «ничего не работает», «файл пропал». Мы прикрутили классификатор на LLM, который переводит это в категорию (принтер, сеть, 1С, доступ, железо), оценивает срочность и маршрутизирует на нужного инженера. Сэкономило где-то 40 минут в день на сортировке.
-
Первичный ответ. На частые вопросы («как подключить принтер», «как восстановить пароль 1С») бот даёт готовые инструкции ещё до того, как заявку берёт инженер. Часть проблем решается без участия человека. Часть — нет, но пользователь уже получил первый шаг.
-
Анализ логов. Когда падает сервер, логи 1С или Windows Event Log — это стена текста. Мы сделали скрипт, который скармливает куски логов в Claude API с промптом «найди аномалии и похожие паттерны», получает короткое резюме, инженер начинает диагностику не с нуля. Работает не идеально, но ускоряет первичный анализ.
-
Автогенерация runbooks. После закрытия инцидента инженер скидывает в бота описание, бот выдаёт черновик runbook в нашем формате. Инженер проверяет и сохраняет в wiki. Раньше runbook откладывался «на потом» и не писался никогда. Теперь пишется почти всегда.
Не работает (пока):
-
Принятие решений по инцидентам. AI может помочь понять причину, но решение «перезагружаем сервер, не перезагружаем сервер» всё равно принимает человек. Цена ошибки слишком высокая, галлюцинации — недопустимы.
-
Работа с нестандартной инфраструктурой клиентов. У многих наших клиентов есть исторические конфигурации, которые нельзя описать в общем виде. Там AI путается. Работает только опыт инженеров.
Этот, кстати, подход — «AI там, где он реально помогает, а не везде, куда можно его воткнуть» — я тащу из IT-аутсорсинга во все остальные наши продуктовые проекты. В PDNGuard он встроен как ядро анализа. В Ecokon — как генератор SEO-контента через Julcha. В RunStart — никак, там AI не нужен, там нужна нормальная автоматизация. Это сознательное решение.
Result
Чем я объективно горжусь:
- Средний стаж договора — 10 лет. Это реально много. Это значит, что клиенты не ищут альтернатив.
- Uptime SLA — 99.5%. По большинству клиентов. По критичной инфраструктуре (онлайн-кассы, 1С) — выше.
- Клиентов 15+. Мы не гонимся за масштабом любой ценой — мы берём тех, с кем можем качественно работать.
- Мониторинг 24/7. Мы узнаём о проблеме раньше, чем клиент.
- Документация на всех клиентов. Это позволяет инженерам заменять друг друга, а бизнесу — быть устойчивым к кадровым рискам.
Чему это научило лично меня
Главное — скучная стабильность стоит дороже ярких подвигов. Клиенты платят не за «мы починили за ночь», а за «у нас никогда ничего не ломалось». Инженер, который написал хороший runbook, ценнее инженера, который пять часов героически чинил то, что можно было починить за пятнадцать минут по процедуре.
Второе — автоматизировать надо рутину, а не удовольствие. Я видел проекты, где команды тратили месяцы на автоматизацию того, что они делали раз в квартал. Это не про эффективность, это про «интересно повозиться». Автоматизировать надо то, что болит каждый день.
Третье — долгие отношения с клиентом важнее «красивых проектов». Продуктовая часть «Консоли» появилась в том числе потому, что за 10 лет аутсорсинга мы поняли, чем именно наши клиенты занимаются и какие у них боли. PDNGuard, Ecokon, Stonekarelia, RunStart — это всё выросло из понимания отрасли, которое даёт только долгая работа руками.
Что дальше
В 2026-м мы расширяем AI-обвязку над аутсорсингом: улучшаем автоклассификацию заявок, готовим предиктивный мониторинг («у этого сервера через месяц посыплется диск»), экспериментируем с голосовым ботом для горячей линии. И продолжаем писать runbooks — потому что это фундамент, без которого ничего не стоит.
Ищете IT-аутсорсинг в Петрозаводске или Карелии? Напишите нам, обсудим.
Павел Гладышев — учредитель ООО «Консоль». Инженер по обслуживанию комплексов автоматизации по основной работе, поэтому слово «надёжность» у него не абстракция, а рабочая категория.