2018 год в технологиях: тренды ИТ и железа

О чем был 2018 в ИТ простыми словами

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

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

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

Важно учитывать и инерцию рынка. Большие вендоры живут циклами: новые поколения «железа» выходят регулярно, но обновление парка занимает годы. В 2018 это особенно ощущалось из-за сочетания факторов: внимания к уязвимостям и обновлениям, давления регуляторов и внутренних политик безопасности, усложнения инфраструктуры (облака, контейнеры, гибридные схемы), роста интереса к ИИ и аналитике, а также ожиданий по круглосуточной поддержке и устойчивости.

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

Главные тренды 2018 года

Если вспомнить 2018 одним набором слов, это были облака, контейнеры, ИИ, безопасность и данные. Но важнее не термины, а то, как они меняли повседневные решения - от выбора серверов до того, как команды выпускают обновления.

Первый заметный сдвиг - гибридные модели. Многие компании перестали спорить «облако или свое» и начали сочетать оба подхода. Чувствительные данные и критичные системы оставляли on-prem, а тесты, резервные мощности и часть сервисов переносили в облако. Это заставило по-новому смотреть на сеть, резервное копирование и единые правила доступа.

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

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

Еще один сдвиг - запрос на надежность и прозрачность цепочки поставок. Организации чаще спрашивали, где и как производится оборудование, кто отвечает за поддержку и насколько предсказуем сервис.

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

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

Безопасность и регуляторы: что изменилось

2018 запомнился тем, что безопасность перестала быть только темой антивируса и фаервола. В начале года широко обсуждались уязвимости уровня процессора (Spectre и Meltdown). Это был неприятный сигнал: проблема может быть не в программе, а глубже - в самом железе и способе выполнения команд.

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

Параллельно усилилось давление со стороны регуляторов и клиентов. GDPR в Европе стал символом нового подхода к персональным данным: меньше собирать, лучше объяснять, где и зачем храните, и уметь доказать, что защищаете. Даже компании вне ЕС почувствовали эффект, если работали с европейскими партнерами или обрабатывали данные пользователей из ЕС.

Типичная реакция бизнеса в 2018 выглядела вполне практично: сначала инвентаризация активов (какие ПК, серверы, ОС и прошивки реально стоят в сети), затем патч-менеджмент с тестовым контуром и понятными сроками установки критических обновлений. Параллельно пересматривали сегментацию сети, резервное копирование (частота, офлайн-копии, регулярные тесты восстановления) и закрепляли ответственность за данные: кто владелец, где хранятся, кто имеет доступ.

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

ПК и рабочие места: что нового было в железе

В 2018 настольные ПК и рабочие станции заметно «повзрослели». Главный сдвиг был простым: больше вычислительной мощности стало доступно не только в дорогих конфигурациях, а в массовых рабочих местах. Это подтолкнуло компании чаще пересматривать стандарты офисных ПК, особенно там, где параллельно открыто много вкладок, крутятся тяжелые таблицы, CRM и видеосвязь.

Процессоры развивались по двум направлениям: больше ядер и выше частоты при сохранении приемлемого теплопакета. На рынке шло активное обновление линеек Intel и AMD. На практике это ощущалось так: в одних сегментах цены и доступность «плавали» из-за дефицитов и перекосов спроса, в других появлялись более выгодные по цене конфигурации, которые раньше считались «почти профессиональными».

Отдельная веха 2018 года - накопители. SSD стали восприниматься как базовый минимум для рабочего места, а NVMe все чаще переходил из разряда «приятно иметь» в норму для тех, кто работает с большими файлами, базами или виртуальными машинами. Вопрос был не только в скорости, но и в том, насколько предсказуемо ПК ведет себя под нагрузкой, когда диск занят.

По форм-факторам заметнее стали моноблоки, тонкие корпуса и сенсорные экраны. Для ресепшена, классов и врачебных постов моноблоки ценили за аккуратность, меньше проводов и более простой монтаж. В Казахстане этот тренд поддерживали и локальные производители, в том числе GSE.kz, развивая линейки отечественных ПК и сенсорных моноблоков - это помогало собирать единый парк и упрощать поддержку.

Если в 2018 вы выбирали «типовой» офисный ПК, чаще всего смотрели на несколько базовых вещей: хватает ли ядер для многозадачности, есть ли SSD (и нужен ли NVMe) под реальные сценарии, есть ли запас по оперативной памяти на 2-3 года, насколько шумит и греется система в плотной рассадке, и насколько удобно обслуживание и сервис.

Серверы и дата-центры: обновления 2018 года

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

Серверные CPU: гонка ядер и прагматичный расчет

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

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

Виртуализация, консолидация и новые требования к хранилищам

В 2018 стало нормой «выжимать» больше VM из одного сервера. Это подталкивало к консолидации, но одновременно повышало цену ошибки: один перегруженный хост мог влиять на десятки сервисов. Поэтому вырос спрос на быстрые дисковые подсистемы. NVMe и all-flash все чаще рассматривали не как роскошь, а как способ снизить задержки и получить стабильные IOPS для баз данных, VDI и аналитики.

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

Типичный сценарий того времени: организация обновляет 2-3 старых стойки и хочет уместить больше сервисов в меньшем числе узлов. В таких проектах часто выигрывали решения «под ключ», где серверы, сеть, СХД и поддержка подбираются вместе.

ИИ и ускорители: что стало массовым

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

Массовость ИИ во многом обеспечили ускорители, в первую очередь GPU. При выборе рабочих станций и серверов стало важнее смотреть не только на процессоры и объем памяти, но и на то, есть ли место и питание под видеокарты, сколько линий PCIe доступно, как устроено охлаждение и насколько надежен блок питания. Для серверов добавлялась практичная деталь: один и тот же проект мог требовать разных конфигураций - от «одной GPU для пилота» до нескольких ускорителей для обучения.

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

Ожидания 2018 чаще всего сводились к нескольким выводам. Быстрый эффект появляется там, где много однотипных операций и понятна метрика качества. Если данных мало или они «грязные», GPU не спасет: проект упрется в подготовку. Часто достаточно простых моделей, но важно встроить результат в процесс (кто и как принимает решение). И наконец, обучение и внедрение - разные задачи: для внедрения важнее стабильность, мониторинг и поддержка.

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

Облака, контейнеры и DevOps: сдвиги 2018

В 2018 многие компании перестали воспринимать облако как «все или ничего». Вместо спора о том, где жить инфраструктуре, начали выбирать, где удобнее жить каждой конкретной задаче.

Контейнеры стали популярны, потому что упрощали перенос приложений между средами. Один и тот же сервис можно было запустить на тестовом сервере, затем в продакшене, а позже перенести в другую площадку без долгих «переупаковок». Kubernetes все чаще воспринимали как общий способ управлять контейнерами: масштабировать, перезапускать при сбоях, выкатывать обновления по шагам.

DevOps в 2018 стал более прикладным. Речь была не про абстрактную «культуру», а про привычки, которые дают измеримую пользу: выпускать изменения чаще и меньше рисковать каждым релизом.

Что в DevOps стало «нормой»

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

Гибридное облако стало компромиссом реальности. Чувствительные данные, критичные системы и то, что требует стабильной задержки, оставляли on-prem. А сервисы, которые удобно быстро менять, тестировать или масштабировать, переносили в облако.

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

Почему барьер входа снизился

К 2018 году стало больше готовых платформ и шаблонов: стандартные кластеры Kubernetes, типовые пайплайны CI/CD, базовые практики безопасности. Это помогало начинать с малого и не строить «идеальную платформу» годами.

Как использовать уроки 2018 для планирования ИТ на 2019-2020

2018 показал простую вещь: выигрывают не те, кто гонится за модой, а те, кто считает риски и обновляет ИТ по плану. В 2019-2020 лучше всего работают понятные шаги, которые связывают безопасность, производительность и поддержку в одну картину.

Начните с короткого, но честного плана работ. Сначала соберите инвентарь: ПК, серверы, сетевое оборудование, лицензии, версии ОС и критичные сервисы (почта, бухгалтерия, медицина, обучение, фронт-офис). Затем выберите 3-5 приоритетов на 12-18 месяцев: патчи и резервные копии, устранение узких мест производительности, прозрачность поставок и импортозамещение (если это важно), удобство для пользователей и 24/7 поддержка ключевых систем. После этого определите модель размещения: on-prem, облако или гибрид. На практике часто нужен гибрид: данные и критичные сервисы остаются внутри, а вторичные нагрузки уносят наружу.

Дальше наметьте цикл обновления на 3 года: рабочие места партиями, серверы по критичности, отдельно план для хранилищ и резервного копирования. И сразу заложите эксплуатацию: запасные части, сроки реакции, регламент восстановления после инцидента.

После 2018 многие компании столкнулись с тем, что обновления безопасности могут снижать производительность, а старые платформы труднее патчить. Поэтому важно заранее тестировать обновления и иметь план отката.

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

В бюджете на 2019-2020 заранее стоит выделить деньги на резервное копирование и тесты восстановления, поддержку и ЗИП (диски, блоки питания, память), обучение сотрудников базовой гигиене безопасности и пилоты (один новый серверный узел или партия ПК), чтобы проверить подход до массового обновления.

Частые ошибки, которые стали заметны в 2018

2018 хорошо показал: проблемы редко появляются из-за «не того бренда». Чаще они вырастают из привычек эксплуатации и планирования.

Самая заметная ошибка была вокруг обновлений. Многие откладывали патчи из страха простоя, особенно на серверах и ключевых рабочих местах. В итоге риск становился выше: уязвимости накапливались, а окно для спокойного обновления сокращалось. Рабочий подход обычно другой: короткие техокна, тестирование на пилотной группе и понятный откат.

Вторая типичная история - покупка серверов «по процессору». В 2018 многие увидели, что прирост по CPU не спасает, если узкое место в дисковой подсистеме, сети или охлаждении. Сервер может быть мощным на бумаге, но медленным в реальной нагрузке.

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

Четвертая ошибка - перенос «все в облако» без расчета. Сюрпризы появлялись в счетах за хранение, трафик и резервное копирование, а также в требованиях к данным и регуляторам.

Пятая - старт ИИ-проекта без базы: нет качественных данных и процесса их обновления, нет владельца результата и нет метрик, по которым видно пользу. Нередко компания покупает серверы и ускорители, но не описывает, какие решения должна улучшить модель и кто будет менять работу отдела после внедрения.

Короткий чеклист: что проверить после обзора 2018

Если вы узнаете в описании 2018 знакомые ситуации, полезнее всего быстро проверить базовые вещи в своей ИТ-среде. Этот список помогает найти риски, которые обычно всплывают уже после инцидента или внезапного сбоя.

• Безопасность: есть ли учет устройств и ПО, установлен ли процесс патч-менеджмента, проверялись ли резервные копии восстановлением, включена ли MFA для почты, VPN и админ-доступов.
• Инфраструктура: посмотрите графики загрузки CPU, RAM и дисков за 30-90 дней, отметьте сетевые узкие места (Wi‑Fi, офисные коммутаторы, каналы до филиалов), оцените темпы роста данных и где заканчивается место.
• Рабочие места: сколько ПК старше 4-5 лет, совместимо ли ключевое ПО с текущей ОС, где логичнее переход на моноблоки (ресепшен, классы, стойки медрегистрации).
• Поддержка и эксплуатация: понятны ли SLA и зоны ответственности, есть ли запас критичных запчастей, используются ли единые стандарты настройки, хватает ли короткого обучения пользователям по частым ошибкам.
• Документы и план: обновлены ли политики данных и доступа, учтены ли требования к закупкам и локальному происхождению оборудования, есть ли план развития на 12-24 месяца с бюджетом и приоритетами.

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

Простой пример: обновление парка ПК и серверов после 2018

Представим организацию: 300 офисных ПК и 10 серверов в небольшой серверной. За год выросла нагрузка (больше 1С/ERP, больше файлов, больше удаленной работы), а после событий 2018 стало ясно, что старые подходы уже не тянут: уязвимости уровня Spectre/Meltdown, новые требования к защите данных и рост ожиданий пользователей по скорости.

Обновление удобнее разложить на этапы, чтобы не остановить работу и не потратить бюджет одним платежом.

• Этап 1 (0-2 месяца): инвентаризация и риски. Какие ПК не тянут ОС и офисные задачи, какие серверы упираются в CPU/RAM/диски, что с резервными копиями и патчами, какие сервисы «критичные».
• Этап 2 (2-6 месяцев): быстрый эффект. Меняем самые проблемные ПК (например, 20-30% парка) и часть старых машин переводим на SSD и добавляем память. На серверах - усиливаем дисковую подсистему под базы и виртуалки, добавляем 10GbE там, где узкое место сеть.
• Этап 3 (6-12 месяцев): ядро инфраструктуры. Планово обновляем оставшиеся ПК, серверы либо меняем на более свежие, либо выносим часть задач в гибрид: почта, архивы, тестовые среды.
• Этап 4 (после 12 месяцев): стандарты и поддержка. Закрепляем единые образы, графики обновлений, политику шифрования и контроль доступа.

По бюджету часто работает правило: 60-70% на рабочие места (замены и апгрейды), 20-30% на серверы и хранение, около 10% на безопасность и резервное копирование. Если важна прозрачность цепочки поставок и сервис «на месте», стоит заранее решить, какие позиции брать у локального производителя и интегратора (например, ПК и серверы, произведенные в Казахстане), а что оставлять как сервис.

Компромиссы обычно простые: «сразу» закрываем безопасность и критичные узкие места (патчи, бэкапы, диски под базы), «позже» делаем комфортные улучшения (мониторы, периферия), «в гибрид» уносим нерегламентированные нагрузки (разработка, аналитические витрины, сезонные пики).

Через 3 месяца и через год лучше смотреть не на ощущения, а на метрики: долю устройств с актуальными обновлениями и включенным шифрованием, количество инцидентов и среднее время восстановления, утилизацию CPU/RAM и задержки дисков на серверах в часы пик, успешность резервного копирования и время проверки восстановления, а также число обращений в поддержку по «тормозит/зависает» на 100 пользователей.

Следующие шаги: как превратить выводы в конкретный план

Урок 2018 простой: обновления легче делать серией небольших решений, чем одним большим и редким проектом. Чтобы не потеряться в трендах, полезно свести выводы в план на одну страницу.

План на одной странице

Хорошая форма - чтобы ее можно было показать руководителю и команде. Достаточно пяти блоков: 3-5 главных рисков (безопасность, простои, нехватка мощности, зависимость от поставок), 3 приоритета на 90 дней, сроки и вехи (пилот, закупка, внедрение), ответственные (владелец процесса, ИБ, ИТ, закупки) и критерии успеха (меньше инцидентов, быстрее работа, понятная поддержка).

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

Запустите пилот, а не полную замену

Пилот снижает риск и помогает понять реальную нагрузку. Обычно достаточно 10-20 рабочих мест или 1-2 узлов в серверной. Например, в бухгалтерии и отделе продаж быстро становится видно, что важнее: быстрый SSD, больше памяти или стабильные драйверы и периферия.

Для пилота заранее договоритесь о двух вещах: кто собирает обратную связь и как вы откатываетесь назад, если что-то пойдет не так.

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

Если вам подходят типовые сценарии (офисные ПК, рабочие станции, rack-серверы, поставка и сервис), можно рассмотреть локально произведенные линейки и поддержку от GSE.kz (gse.kz) как один из вариантов для пилота и дальнейшего тиражирования.