Як взяти мережеву інфраструктуру під контроль. Глава перша. Утримання

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

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

Отже, початкові умови.

Ви на новому місці роботи або у вас підвищення, або ви вирішили по-новому поглянути на свої обов'язки. Мережа компанії – це зона відповідальності. Вам багато в чому це челендж і нове, що дещо виправдовує наставницький тон цієї статті :). Але, сподіваюся, що стаття так само може бути корисною і будь-якому мережевому інженеру.

Ваша перша стратегічна мета – навчитися протистояти ентропії та утримати рівень сервісу, що надається.

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

Обладнання

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

Знов-таки, може бути по-різному. Припускаю, що десь, наприклад, це будуть питання безпеки, а десь питання, пов'язані з безперервністю сервісу, а десь, можливо, ще щось. Чому б ні?

Припустимо для визначеності, що це все ж таки безперервність сервісу (так було у всіх компаніях, де працював я).

Тоді треба розпочинати з обладнання. Ось список тем, на які слід звернути увагу:

• класифікація обладнання за ступенем критичності
• резервування критичного обладнання
• підтримка, ліцензії

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

Приклад

Припустимо, ми говоримо про кореневий комутатор у дата-центрі.

Оскільки ми домовилися, що безперервність сервісу є найважливішим критерієм, то розумно забезпечити «гаряче» резервування (redundancy) цього обладнання. Але це ще не все. Ви так само повинні визначитися з тим, скільки часу, у разі поломки першого комутатора, для вас прийнятно жити тільки з одним комутатором, адже є ризик, що і він поламається.

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

Так, якщо було вирішено, що, за умови невеликої ймовірності подвійної поломки, робота протягом 4х годин на одному комутаторі, в принципі, прийнятна, то ви можете просто взяти відповідну підтримку (за якою обладнання буде замінено протягом 4 годин).

Але є ризик, що не доставлять. На жаль, якось ми опинилися у такій ситуації. Замість чотирьох годин обладнання їхало тиждень!

Тому цей ризик теж потрібно обговорити і, можливо, вам буде правильніше купити ще один комутатор (третій) і тримати його в ЗІПі («холодне» резервування) або використовувати в лабораторних цілях.

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

Вам не пробачать, якщо ви забудете продовжити підтримку і наступного дня після того, як вона закінчиться, ваше обладнання зламається.

аварійні роботи

Щоб не відбулося у вашій мережі, в ідеалі, ви повинні зберегти доступ до вашого мережного обладнання.

Важливо! У вас повинен бути консольний доступ до всього обладнання і цей доступ не повинен залежати від працездатності мережі передачі даних (data).

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

В обов'язковому порядку там мають бути

• інформація, необхідна для відкриття заявки на підтримку вендора чи інтегратора
• інформація, як потрапити на будь-яке обладнання (консоль, management)

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

Партнери

Тепер вам необхідно оцінити ризики, пов'язані з партнерами. Зазвичай це

• інтернет-провайдери та точки обміну трафіком (IX)
• провайдери каналів зв'язку

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

• що буде, якщо інтернет-провайдер X перестане з якоїсь причини надавати вам сервіс?
• Чи вистачить вам лінії пропускання інших провайдерів?
• наскільки гарною залишиться зв'язність?
• наскільки незалежними є ваші інтернет-провайдери і чи не призведе серйозна аварія одного з них до проблем з іншими?
• скільки оптичних введень у ваш дата-центр?
• що буде якщо один із вводів буде повністю зруйнований?

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

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

Бекап

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

Важливо! Зробіть бекап щоденним. Не такий вже великий обсяг даних, щоб економити на цьому. Вранці черговий інженер (або ви) повинен отримувати звіт від системи, в якому явно вказується успішний або не успішний був бекап, і у разі неуспішного бекапу проблема має бути вирішена або має бути створений тикет (див. процеси мережного відділу).

Версії софту

Питання про те, чи варто виробляти апгрейд софту обладнання не так однозначний. З одного боку, старі версії – це відомі баги та вразливості, але з іншого, новий софт – це по-перше, не завжди безболісна процедура апгрейду, а по-друге – нові баги та вразливості.

Тут необхідно знайти оптимальний варіант. Декілька очевидних рекомендацій

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

На цьому етапі, маючи консольний доступ до обладнання, інформацію про підтримку та опис процедури апгрейду, ви, в принципі, готові до цього кроку. Ідеальний варіант, коли у вас є лабораторне обладнання, де ви можете перевірити всю процедуру, але, на жаль, таке буває не часто.

У разі критичного обладнання, можна звернутися на підтримку вендора з проханням допомогти вам у проведенні апгрейду.

Тикетна система

Тепер ви можете озирнутися на всі боки. Вам потрібно налагодити процеси взаємодії з іншими підрозділами та усередині відділу.

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

Тикетна система - це по суті ваш інтерфейс для внутрішніх та зовнішніх комунікацій, і ви повинні з достатнім ступенем детальності описати цей інтерфейс.

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

Приклад

Почнемо з того, що часто замовники доступу формулюють своє бажання незрозумілою мережевим інженером мовою, а саме, мовою програми, наприклад, “відкрийте мені доступ до 1C”.

Тому ми ніколи не приймали запити безпосередньо від таких користувачів.
І це була перша вимога

• запити на надання доступів повинні надходити від технічних відділів (у нашому випадку це були unix, windows, helpdesk інженери)

Другою вимогою є те, що

• цей доступ має бути запротоколований (технічним відділом, від якого ми цей запит отримали) і як запит ми отримуємо посилання на цей запротоколований доступ

Форма цього запиту має бути зрозумілою нам, тобто

• запит повинен містити інформацію про те, з якою та в яку підмережі має бути відкритий доступ, а також про протокол та (у разі tcp/udp) порти

Так само там має бути вказано

• опис для чого цей доступ відкривається
• тимчасовий або постійний (якщо тимчасовий, то до якого числа)

І дуже важливий пункт це аппруви.

• від керівника відділу, який ініціював доступ (наприклад, бухгалтерії)
• від керівника технічного відділу, звідки цей запит надійшов до мережного відділу (наприклад, helpdesk)

При цьому "власником" цього доступу вважається керівник відділу, який ініціював доступ (бухгалтерія у нашому прикладі), і він відповідальний за те, щоб сторінка із запротокольованими доступами для цього відділу залишалася актуальною.

Логування

Це те, в чому можна потонути. Але якщо ви хочете впровадити проактивний підхід, то вам потрібно навчитися справлятися із цим потоком даних.

Ось кілька практичних рекомендацій:

• переглядати логи потрібно щодня
• у разі планового перегляду (а не аварійної ситуації) можна обмежитися рівнями критичності (severity) 0, 1, 2 і додати обрані патерни з інших рівнів, якщо вважаєте за потрібне
• напишіть скрипт, що париться логи та ігнорує ті логи, патерни яких ви додали в ігнор-лист

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

моніторинг

Це не рідкість, коли у компанії відсутня система моніторингу. Ви можете, наприклад, покладатися на логи, але обладнання може просто «померти», не встигнувши нічого «сказати», або udp пакет syslog протоколу може загубитися і не долетіти. Загалом, звісно, ​​активний моніторинг важливий та потрібен.

Два найбільш затребувані в моїй практиці приклади:

• моніторинг завантаження каналів зв'язку, критичних лінків (наприклад, підключення до провайдерів). Дозволяють проактивно побачити потенційну проблему деградації сервісу через втрату трафіку та відповідно уникнути її.
• графіки, побудовані з урахуванням NetFlow. Вони дозволяють легко знаходити аномалії у трафіку та дуже корисні для виявлення деяких простих, але суттєвих видів хакерських атак.

Важливо! Налаштуйте SMS повідомлення для найбільш критичних подій. Це стосується як моніторингу, так і логування. Якщо у вас немає чергової зміни, то SMS також повинні приходити і в неробочий час.

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

Контроль змін

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

Декілька порад:

• використовуйте систему тикету для детального опису того, що було зроблено в рамках цього тикету, наприклад, копіюючи застосовану конфігурацію в тикет
• використовуйте можливості коментарів на мережевому устаткуванні (наприклад, commit comment на Juniper). Ви можете записати номер тікету
• використовуйте diff ваших бекапів конфігурації

Ви можете ввести це як процес, щодня переглядаючи всі тикети щодо змін.

процеси

Ви повинні формалізувати та описати процеси у вашій команді. Якщо ви дійшли до цього моменту, то у вашій команді вже повинні працювати щонайменше такі процеси:

Щоденні процеси:

• робота з тикетами
• робота з логами
• контроль змін
• щоденний чек лист

Щорічні процеси:

• продовження гарантій, ліцензій

Асинхронні процеси:

• реакція на різні аварійні ситуації

Висновок першої частини

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

Поки, як ви бачите, ви нічого не покращили у вашій мережі. Якщо були вразливі в безпеці, то вони й залишилися, якщо був поганий дизайн, він залишився. Поки ви не застосували своїх навичок та знань мережного інженера, на яке було витрачено швидше за все багато часу, зусиль, а іноді й грошей. Але спочатку потрібно створити (або зміцнити) фундамент, а потім уже зайнятися будівництвом.

Про те, як шукати та усувати помилки, а потім і покращувати вашу інфраструктуру – про це такі частини.

Звісно, ​​не обов'язково все робити послідовно. Час може бути критичним. Робіть паралельно, якщо дозволяють ресурси.

І важливе доповнення. Спілкуйтесь, питайте, радьтеся з вашою командою. Зрештою, саме їм все це підтримувати і робити.

Джерело: habr.com