The post has been translated automatically. Original language: Russian
There are several areas that have a significant impact on the development of the data center industry in recent years.
The growing load from the AI infrastructure. Training and inference of machine learning models require a fundamentally different density of computing power and, consequently, different solutions for cooling and energy supply of racks — this changes the requirements for designing new sites.
Edge computing. Part of the computing and data processing is shifting closer to the user — to regional and local points of presence in order to reduce latency for services sensitive to it: video, IoT, financial transactions.
Sustainable development and energy efficiency. Reducing PUE, using fracking, and switching to more efficient cooling schemes are becoming not just an image factor, but a direct cost—saving item for data center operators and, consequently, for their customers.
Stricter security and compliance requirements. The growing number of cyber attacks and the development of data protection regulation are pushing data centers to invest in stricter physical and information security procedures, as well as transparent reporting for customers.
Hybrid and multi-cloud architectures are becoming the norm, not the exception — businesses are less likely to choose a single infrastructure provider, preferring to distribute risks between multiple sites and clouds.
These trends should be taken into account now when planning infrastructure for the next 2-3 years, and not after the fact, when current solutions will no longer cope with the load.
Большинство серьёзных инцидентов в инфраструктуре начинаются не со сложных атак или отказа оборудования, а с обычного изменения: обновили конфигурацию, заменили модуль, применили патч — и что-то пошло не так в самый неподходящий момент. Отсюда и родилась практика change management — процесса, который регламентирует, как вносятся изменения в продакшн-инфраструктуру.
Смысл не в бюрократии ради бюрократии, а в том, чтобы у каждого изменения были три обязательных элемента.
Понятная причина и объём. Что именно меняется, зачем, и какие компоненты это затронет — сформулировано до, а не после того, как что-то сломалось.
План отката. Если изменение вызывает проблему, должно быть заранее известно, как быстро вернуться к рабочему состоянию — а не придумывать план отката в момент, когда сервис уже недоступен.
Согласованное окно. Плановые изменения выполняются в заранее определённое время с минимальной нагрузкой, а не «между делом» в рабочие часы, и о них уведомлены все, кого это может затронуть.
Для небольшой команды полноценный ITIL-процесс с комитетами по изменениям — избыточен. Но базовый минимум работает даже в компании из нескольких человек: любое изменение конфигурации продакшн-среды фиксируется в едином месте (тикет, канал, таблица — не важно где, важно что не в голове одного инженера), у него есть автор, причина и результат проверки после применения.
Отдельно стоит выделить «аварийные» изменения — те, что нужно внести немедленно для устранения инцидента. Для них тоже нужен свой мини-регламент: кто имеет право принять решение без обычного согласования, и как задокументировать это изменение постфактум, чтобы оно не выпало из общей картины.
Регламент change management не ускоряет работу в моменте — наоборот, добавляет шаг перед изменением. Но он системно снижает число инцидентов, вызванных человеческим фактором, а именно они, по данным большинства отраслевых отчётов о простоях, остаются основной причиной незапланированных сбоев.
Share
