Техническое перевооружение в компании N: как мы перестали чинить старье и перешли к циклическому обновлению

Оглав ление

О терминах
С чего начали
Организация: ничего лишнего
Проектирование плавной замены
Техническая реализация: три попытки сервера 1С
Регламенты и люди
Итоги первого этапа
Резюме для тех, кто планирует похожее
 

О те рминах

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

Формально правильно говорить «управление жизненным циклом ИТ-активов» (ITAM) или «процесс обновления парка». Но бизнес-заказчику без разницы, как это называется по ITIL. Ему важно: деньги, сроки, риски. Поэтому внутри компании мы используем «техперевооружение». Это перевод с корпоративного на человеческий.

С чего начали

Мы не нанимали интегратора под ключ и не покупали дорогой ITAM-софт. Не потому, что жалели денег – внедрение корпоративной системы учёта активов занимает от года. Мы не могли ждать год…

Первым делом провели аудит своими силами. Собрали по всем ПК:

• дата закупки (по бухгалтерии или по серийному номеру).
• поколение процессора.
• тип и объем RAM.
• тип накопителя (HDD или SSD).

Для серверов и сетевого оборудования – даты окончания поддержки (EOS/EOL)

Выявили три базовые проблемы, которые бизнес понимал без диаграмм:

1. Безопасность. Часть ПК не тянет современную ОС, на серверы – актуальные гипервизоры, сетевое оборудование – современные протоколы шифрования.
2. Производительность. Пользователи жаловались массово. Не единичные «у меня тормозит», а поток «работать невозможно».
3. Экономика. Искать совместимые комплектующие для десятилетней машины – донорство с непредсказуемым результатом. Цена такого апгрейда часто упирается в стоимость нового системного блока.

Цель поставили прямо: перестать чинить то, что пора выкинуть. Сделать инфраструктуру платформой, на которой можно разворачивать новые сервисы, не оглядываясь на «а потянет ли железо».

Организация: ничего лишнего

Клиентские устройства. ПК разделили на два профиля: офисные и продвинутые (САПР, разработка, аналитика). Офисные живут 5–7 лет. Продвинутые через три года ротируем в офисный парк – там они еще 3–4 года работают без нареканий.

Критерий приоритизации по этапам простым:

• ПК с устаревшей DDR3 (и старше) – под замену в первую очередь. Часть в доноры, часть под списание.
• ПК с DDR4 – сортировали по году выпуска процессора.

Серверное и сетевое оборудование. Здесь подход другой. Мы не можем менять серверы каждый год. Поэтому зафиксировали правило:

• Покупаем, если вендор не объявил EOS (конец продаж).
• Если объявлен EOL (конец поддержки) – переводим оборудование из продуктивного контура в тестовый или на некритичные узлы.
• Если EOL наступил, а замена невозможна – решение принимает архитектор и отвечает за него.

Аналогичный подход CISA закрепила для госорганов США: оборудование без обновлений безопасности надо менять в течение 18 месяцев. Мы под американскую юрисдикцию не попадаем, но логика «оборудование без поддержки – неприемлемый риск» нам близка. У нас сроки гибче, но суть та же.

Проектирование плавной замены

Самое трудное – не решить, что менять, а сделать замену регулярной, предсказуемой, без авралов.

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

Под эту цифру провели тендер не на разовую поставку, а на годовой контракт с ежемесячной отгрузкой. Поставщик фиксирует цену на год, мы гарантируем объём, но с правом корректировки в пределах 20 %. Это оказалось ключевым: если в декабре у людей отчётный период и трогать их нельзя, мы просто переносим поставку. Деньги не замораживаются, склад не забивается.

Резерв. Держим на складе 2–3 комплекта под каждую модель плюс ходовые комплектующие (блоки питания, память). Раньше на замену сгоревшего блока уходило 3–5 дней (заявка, согласование, закупка). Сейчас – час.

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

Техническая реализация: три попытки сервера 1С

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

С инфраструктурой – сложнее.

Мы меняли сервер, на котором крутился 1С. Первая попытка – откат через два часа. Вторая – откат через четыре. Проблема оказалась в недокументированной особенности старой инсталляции. Мы выяснили и решили проблему только с третьего захода.

После этого внедрили правило:

• План работ утверждается с указанием времени отката (обычно 4 часа).
• Не уложились – возвращаем старое оборудование.
• Ретроспектива, корректировка плана, новая попытка – только после утверждения изменённого плана.

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

Регламенты и люди

Когда мы начинали, в штате не было специалистов под новое оборудование. Мы пошли к поставщику с условием: вы поставляете железо и проводите обучение двух наших инженеров (не двухчасовой вебинар, а полноценный курс с аттестацией).

Дальше применили схему, которую потом нигде в методичках не встречал, но она сработала.

1. Подрядчик выполняет монтаж и настройку.
2. Наши инженеры работают «руками» под его присмотром.
3. После завершения работ инженер пишет статью в базу знаний: что делали, с какими сложностями столкнулись, какие параметры пришлось менять.
4. Статья уходит на рецензию инженеру подрядчика. Он указывает неточности, пробелы, неправильные формулировки.
5. Финальная версия проходит ревью у руководителя и дублера.

Так совместили накопление знаний с наставничеством. Сейчас любой запрос к подрядчику – не просто «сделайте». Инженер фиксирует проблему, подрядчик даёт решение, инженер оформляет ретроспективу. Через 3–4 таких цикла компетенция переходит внутрь.

Что еще изменили в регламентах:

• Стандарты оснащения рабочих мест – ушли от субъективных «дайте мне мощнее».
• Регламент замены устаревшего оборудования – привязали к плану, а не к жалобам.
• Инструкции пользователей по новой ОС.

Итоги первого этапа

Проект не завершён, мы в середине пути. Но уже сейчас:

• 0 инцидентов с оборудованием за последние полгода (раньше было 3–4 в месяц). Не потому, что чинить стали лучше – чинить стало нечего.
• Прекратились массовые жалобы на тормоза. Единичные остались, но это либо конкретные проблемы приложений, либо редкие артефакты.
• Бюджет на закупку техники стал плоским. Отклонения от плана – не более 2% в квартал. Для бизнеса это предсказуемо. ИТ-службу перестали дёргать вопросом «а почему опять деньги просите?».

Главная сложность – компетенции. Держать в штате узких специалистов под каждую единицу оборудования мы не можем. Поэтому разделили:

• То, что обязаны уметь сами – закрыли обучением и наставничеством.
• Всё остальное – отдали на аутсорс (частично или полностью, включая SaaS).

Резюме для тех, кто планирует похожее

Не пытайтесь купить «процесс» как коробочный продукт. Процесс собирается из аудита, ограничений поставщиков, реальной загрузки людей и бюджетного цикла. Инструменты вторичны. Первичны две вещи: регулярность и предсказуемость затрат.

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