Всі помиляються з VLAN, але у De Novo тільки один раз — адмін хмарної інфраструктури про свою роботу

Системний інженер у великому хмарному операторі — це людина, від дій якої залежить працездатність банків, державних сервісів і мільйонів користувачів. Євген працює в De Novo вже шостий рік. Він розповів про адміністрування в прикладному та широкому сенсі. Отже, у цьому матеріалі ви дізнаєтеся: як збирається та скільки важить приватна хмара, чому зумерам нецікаво працювати адміністраторами та чому ChatGPT стає викликом для інженерів і до чого тут клієнти технічної підтримки.

Я вийшов зі співбесіди мокрий

У De Novo я потрапив не з першого разу — спочатку навіть думав не йти на співбесіду. Тоді мені здавалося, що не вистачає хард-скілів, тому я відмовився і сказав, що це неактуально. Але згодом повернувся до цього питання і зрештою зрозумів, що хмари та стек хмарних технологій — це наступний етап мого розвитку як адміністратора.

Я подався знову, пройшов кілька етапів співбесід і долучився до команди, з якою вже працюю п’ять років. Фінальна розмова — це зустріч з СТО De Novo Геннадієм Карповим, після якої фактично й ухвалюється остаточне рішення. До цього інтерв’ю взагалі доходять одиниці, і перед ним відсіюється дуже багато кандидатів. Сам факт його проходження вже багато говорить про інженера хмарної інфраструктури.

На співбесіді з Геннадієм Карповим питання були, м’яко кажучи, не з простих. Крім базового набору знань системного адміністратора, потрібно розуміння того, як це працює «під капотом». І тут стане в пригоді все, і практичний досвід роботи системним адміністратором, і теоретичні «адмінські» знання, а також знання, отримані у ВНЗ, та навіть у школі. 

Наприклад, розрахунок мінімального RTT (Round-Trip Time) між Києвом і Франкфуртом — тобто затримку, зумовлену передусім відстанню, яку сигнал має подолати. Звичайна шкільна задача на час, відстань і швидкість (світла). Плюс фізика (коефіцієнт заломлення світла, при проходженні через скло). І з «адмінської» практики — затримки, зумовлені обладнанням. 
Теоретичні знання та «проєкція» цих знань в практичну площину, чи навпаки. 
Практично дуже просто перевірити ці затримки, користуючись простим пошуком. А от коли мова йде про те, чим це зумовлено і як це повинно працювати, або чому працює некоректно — потрібно вмикати «голову».
І це лише один із таких прикладів.

Ми тоді спілкувалися близько трьох годин, і я вийшов буквально весь мокрий. Те, що не всі доходять до етапу співбесіди з нашим CTO, — це нормальний процес. Це складний фільтр, який допомагає ще на статрі зрозуміти, чи збігаються наші підходи та технічний драйв. Якщо людині складно на цьому етапі, то в реальних критичних ситуаціях у дата-центрі нам обом було б ще важче.

40 мільйонів людей залежать від кнопки

Інженер хмари у нашому напрямку — це не просто людина, яка підтримує інфраструктуру. На цій інфраструктурі запущені «живі» клієнтські сервіси, тому будь-яка наша дія може мати зовнішній ефект. Ти можеш щось натиснути — і 40 мільйонів людей одразу відчують наслідки. Наприклад, можуть перестати працювати державні сервіси, банки, турнікети в метро чи інші системи, що залежать від інфраструктури.

Тут потрібно мати більше клепки і бути уважнішим — і це, мабуть, не «трохи», а суттєво більше. Бо рівень і якість клієнтів тут інший, і відповідальність значно вища, ніж на будь-якому іншому підприємстві. Тому робота адміністратора в хмарній інфраструктурі — це передусім велика відповідальність. Звісно, я намагаюся про це багато не думати, бо це починає тиснути психологічно, але десь глибоко все одно відчувається напруження. І, мабуть, саме тому це не зовсім про «звичайного адміна у светрі з бородою». 

У De Novo є два типи адміністраторів: ті, хто працює з внутрішньою інфраструктурою, і ті, хто працює з хмарою та B2B-клієнтами. У другому випадку ти взаємодієш уже не просто з системами, а з бізнесом і його сервісами. Адміністратор впливає на розвиток рішень у межах своєї експертизи: фіксує потреби або технічні обмеження і передає їх у відділ R&D, де вони перетворюються на задачі і бізнес-стратегії. Найбільший вплив він має під час роботи з конкретними технічними запитами — саме там визначає, що і як можна реалізувати.

Клієнти зазвичай звертаються вже з проблемами, завданнями, тоді як ідеї та побажання проходять через менеджера й далі потрапляють у R&D. Тому роль адміністратора — це 50 на 50: він і адмініструє інфраструктуру, і долучається до R&D в межах своєї зони відповідальності.

За п'ять років переніс тонну заліза

Процес створення приватної хмари — це чітко регламентований цикл, який за умови наявності всіх компонентів на складі займає щонайменше два тижні. Близько 95% технічних етапів проходять безпосередньо через адміністраторів. Решта — це зона архітекторів і старших спеціалістів, оскільки майже в кожній такій архітектурі є досить складні моменти, як-от наприклад, інтеграції з інформаційними системами клієнтів, що потребують досить глибоких знань та навичок рівня провідних експертів чи архітекторів. 

Але запуск приватної хмари — це не лише про фізичну збірку. Все починається із заявки, потім визначаємо команду, збираємо комплект серверів, комутаторів, менеджмент-комутаторів, дисків, відеокарт за потреби, а також усіх компонентів комутації та іншої інфраструктури. Коли комплект зібрано, настає етап фізичного монтажу в стійки. 

Якщо врахувати, що один сервер важить 10–20 кілограмів, а весь комплекс обладнання приватної хмари в середньому витягує на 500 кілограмів, то за 4–5 років роботи через мої руки пройшла щонайменше тонна «заліза». 

Після фізичної збірки ми переходимо до логічного налаштування: підключаємо менеджмент-мережу, встановлюємо гіпервізори та розгортаємо ключові компоненти, як-от ПЗ стеку віртуалізації, інфраструктурні компоненти. Саме на цьому етапі обладнання перетворюється на інтелектуальну платформу. Коли комплекс повністю зібраний і налаштований, проводяться jumpstart-сесії для клієнта: адміністратор демонструє представникам замовника базові сценарії та процедури роботи з комплексом — як заходити в систему, створювати VM та виконувати основні операції з ними, налаштовувати прикладні мережі, тощо. Після цього клієнт може самостійно працювати з приватною хмарою.

Одна помилка у VLAN — і я «відрізав» собі доступ до менеджмент-мережі

Був інцидент з VLAN — логічними сегментами мережі для ізоляції трафіку та мікросегментації. Якщо на комутаторі доступу некоректно внести конфігурацію — наприклад, помилитися в параметрах команди або пропустити ADD і виконати її в іншому вигляді, то може «відпасти» все. У результаті це може призвести до втрати доступу як до клієнтського трафіку, так і до менеджмент-мережі, залежно від того, де саме сталася помилка.

У мене якраз так і сталося: через помилку в налаштуваннях я фактично «відрізав» собі доступ до менеджмент-мережі. В нашій інфраструктурі доступ організований через десятки VLAN, і при додаванні нової потрібно правильно вказувати параметри. Якщо помилитися з VLAN ID або не вказати ADD, конфігурація може змінитися некоректно. Як наслідок — ноги та консольний кабель у руки і спринт у ЦОД. Клієнтські сервіси, на щастя, не постраждали, але керування було тимчасово недоступне.

Такі історії добре запам’ятовуються. У нас є навіть жарт від СTO De Novo: «Всі помиляються з VLAN, але у De Novo тільки один раз».

Це був перший інцидент у дата-центрі за 15 років

Це була субота, 26 квітня — річниця Чорнобильської трагедії. Я був удома близько восьмої ранку. Напередодні тиждень минув спокійно, нічого не передвіщало проблем. Але раптово в робочому чаті почали з’являтися повідомлення: «світло вимкнули». 

Того дня у ЦОД проводили другий етап масштабної планової модернізації безперебійного живлення. У якийсь момент стався повний блекаут. Енергосистему ЦОД вдалося відновити за 14 хвилин. Якщо порівнювати з середньосвітовими показниками галузі, які становлять понад дві години на відновлення, спрацювали надзвичайно оперативно.

Стандартна реакція на інцидент у De Novo відпрацьована до автоматизму. Частина хмарної команди виїхали безпосередньо на майданчик, інші підключились дистанційно після відновлення живлення. Далі почалася кропітка робота з відновлення хмарних сервісів. Більшість систем піднялися автоматично, проте деякі компоненти, зокрема складні сховища та специфічні клієнтські платформи, потребували ручного втручання та перевірки кожного компонента комплексу перед запуском. Основну частину сервісів ми стабілізували протягом 30-40 хвилин, хоча деякі артефакти, переважно невидимі клієнтам, усували ще певний час, зокрема із залученням підтримки вендора.

Проте слід сказати, що до цього інциденту дата-центр працював безперервно 15 років. 

Нехай клієнти мене правильно зрозуміють, але, здається, це був своєчасний і корисний тест-драйв щодо швидкого відновлення, враховуючи, що триває війна. 

«Бойові маги» та клієнти, які приносять задачі з ChatGPT

У нашій професії існує своя градація спеціалістів. Варто зауважити, що будь-яка класифікація є досить умовною. Це радше наш внутрішній адмінський фольклор — спосіб з іронією подивитися на щоденні робочі процеси та краще зрозуміти потреби тих, хто до нас звертається.

«Бойові» — це ті, хто працює «руками», оперативно керує інфраструктурою та вирішує задачі тут і зараз. Я відношу себе саме до них, мені комфортніше в експлуатації. «Бойові маги» — це наступний рівень, люди архітектури та глобальних процесів, як-от наш керівник центру управління хмарними сервісами, який пройшов шлях від адміна до «мага» ще до появи сучасних хмарних рішень. Цей баланс сил дозволяє нам ефективно працювати з найрізноманітнішими запитами.

Якщо з тобою працює «бойовий маг» з боку клієнта, вважай, що тобі пощастило — він найчастіше пропонує цікаві завдання. 

Для адміністратора клієнт — це насамперед задача. У нас немає окремих метрик «настрою», але є чіткий регламентований SLA та пріоритизація. Ідеальний варіант — коли ми з клієнтом говоримо однією мовою. Існує категорія досвідчених адміністраторів: вони звертаються рідко, але завжди по суті, одразу надаючи всю необхідну інформацію для діагностики. Є й «автономні» клієнти — вони налаштували систему один раз і далі працюють самостійно, періодично лише ініціюючи зміни ресурсів.

Звісно, не всі мають глибоку технічну підготовку, і це цілком нормально. Є користувачі, яким потрібен простий і передбачуваний результат без занурення в технічні деталі. Для них ми намагаємося розкладати інструкції максимально детально: зі скриншотами, стрілочками та покроковими алгоритмами. 
Є клієнти з більш емоційним стилем спілкування. Вони можуть писати хаотично й очікувати миттєвої реакції. У таких випадках наше завдання — максимально перекласти емоції на мову технічних ситуацій і якнайшвидше допомогти.

Із нових трендів — клієнти, які активно використовують ChatGPT для формування технічних задач. Іноді нам надсилають скріншоти відповідей ChatGPT із проханням «перевірити». Виходить цікава ситуація: техпідтримка De Novo фактично стає ревізором знань штучного інтелекту. Складнощі виникають тоді, коли ШІ вигадує функціонал, якого не існує в системі, а клієнт намагається побудувати на цьому свою роботу.

Ще один нюанс — культура читання документації. Ми вкладаємо багато сил у посібники, виділяючи ключові дії червоним кольором. І коли я це роблю — це не спроба «тиснути» на клієнта, а щире бажання сфокусувати його увагу на критично важливих моментах. Ми фактично адаптуємо загальну логіку хмари під конкретне середовище замовника, щоб йому було максимально комфортно.

Зрештою, незалежно від того, чи прийшов клієнт із досвідченим адміном, чи з порадою від нейромережі, моя задача незмінна — забезпечити стабільність системи. Адже за кожним зверненням стоїть реальний бізнес, який має працювати безперебійно.

Чому сапорт не чіпає системи клієнта і де проходить межа відповідальності

Існує чітка зона демаркації — рівень, на якому закінчується відповідальність техпідтримки і починається відповідальність клієнта. Наприклад, ми можемо додати ресурси до віртуального дата-центру, але не виконуємо дії всередині віртуальних машин, як-от розширення диска — це зона відповідальності клієнта. Якщо щось піде не так, це може вплинути на сервіси й створити фінансові та операційні ризики. Тому клієнт виконує такі дії самостійно, а ми допомагаємо з помилками або консультаціями. Я можу розібратися та підказати, але не натисну кнопку.

Що особливо цінують наші клієнти, то це організація технічної підтримки. Головною перевагою, що відрізняє нас від інших провайдерів, те що у клієнта є прямий доступ до інженера. Наші фахівці закривають компетенції одразу L1-L3. Тобто відсутні люди, які лише приймають звернення і переадресовують. Фактично клієнт одразу потрапляє до людини, яка вирішує запит. 

Інформація передається швидше через меншу кількість рівнів. Хоча іноді всі задачі накладаються одночасно — дзвінки, інциденти та інші процеси. У такі моменти буває складно, і це, мабуть, єдиний недолік. 

Сисадміни — не «динозаври», а першопрохідці

Ззовні може здаватися, що це щось «старе», але насправді йдеться про фахівців із глибокою експертизою та великим досвідом. Це не «мамонти», яких варто списувати, а швидше першопрохідці, які стояли біля витоків інфраструктури й розвивали її з нуля.

Ті, хто піднімав інфраструктуру на ранніх етапах, навпаки добре бачать їхню логіку — глибше і ширше, ніж це часто доступно без такого досвіду. Тому їхній внесок часто недооцінюють просто через різницю поколінь або підходів.

У цьому й полягає перекошення: молодші спеціалісти інколи уникають взаємодії, а старші — не завжди готові довго пояснювати. У результаті виникає не проблема компетенції, а проблема комунікації.

Молодші спеціалісти мають тягнутися до більш досвідчених, щоб переймати базу і практику. Це той самий «накопичений час у професії» так звані «жопогодини», який формує рівень інженера. Як і в музиці: чим більше годин практики, тим вищий рівень.

Тому замість того, щоб сприймати досвідчених фахівців як «динозаврів», варто розглядати їх як джерело знань і практики, до якого має сенс звертатися.

Професія сисадміна не зникне — але у світі ШІ вона трансформується, і це змінює правила гри

Сисадміни нікуди не зникнуть, адже автоматизацію теж потрібно налаштовувати й підтримувати. Ймовірно, ця роль частково перепрофілюється. Значну частину задач в IT неможливо передати штучному інтелекту — вони потребують людського мислення та прийняття рішень. ШІ буде розвиватися, але в найближчі роки, а можливо й десятиліття, людей не замінить.

Паралельно з цим з’явилися DevOps та інші спеціалізації, а межі між ними поступово стиратимуться. Людина з технічним бекграундом зможе переходити між ролями й розширювати свою експертизу, не обмежуючись одним напрямом.

Щодо «заліза» та інфраструктури — значна частина роботи й надалі залишатиметься ручною. Фізичне обладнання потрібно встановлювати, обслуговувати й замінювати. Автоматизація працює там, де інфраструктура з самого початку під неї спроєктована, але це не завжди можливо і не завжди економічно доцільно.

Як приклад можна подивитися на склади. Раніше все робили вручну, потім з’явилися кари. Щоб вони нормально працювали, довелося стандартизувати палети — і це був процес, який займав роки. Далі з’явилися автоматичні системи з computer vision, які вже можуть самі переміщати товари. Але і для них усе впирається в підготовлену інфраструктуру: однакові відстані, стандартизація простору, зрозумілі маршрути.

Тому системний адміністратор поступово перетворюється на інженера інфраструктури або DevOps-спеціаліста, який не просто «лагодить комп’ютери», а керує складною цифровою екосистемою. Замість фізичних серверів буде більше хмарної інфраструктури (AWS, Azure, GCP), контейнерних технологій на кшталт Docker і Kubernetes, автоматизації через скрипти та DevOps-підходи, а також використання ШІ для моніторингу й підтримки систем.

Зумерам нецікаво розбиратися в першопричинах — їм легше «пофіксити»

Я бачу різницю між тими, хто приходить у професію після 30, і тими, хто після 20. Ті, хто молодші, швидко схоплюють нове, але їм часто бракує бази й досвіду. Через це мислення ще «не докручене» — немає тієї глибини розуміння, яка дозволяє системно працювати.

З поколінням Z часто буває так, що вони мають завищені очікування від компанії, при цьому від себе — нижчі. Вони приходять у професію і фактично бачать систему «з нуля», без попередньо накопиченого досвіду і контексту, який формує розуміння процесів. У результаті з’являється підхід «натиснув кнопку — отримав результат»: щось зламалося — замінили компонент, система підхопила, і кластер знову працює. Але без розуміння того, як усе працює «під капотом», складно діагностувати першопричини і бачити зв’язки між компонентами.

Навіть робота зі старими технологіями чи мережами дає цей фундамент. Теорія на кшталт TCP/IP чи моделі OSI не працює сама по собі — її потрібно «промацати» на практиці, щоб розуміти, на якому рівні виникає проблема і як відрізнити мережевий рівень від application-рівня. Якщо цієї бази не буде, це може стати викликом для індустрії. Через 10 років ми ризикуємо отримати фахівців, які поверхнево розумітимуть, як усе працює всередині.