Гэты артыкул з'яўляецца першым у цыкле артыкулаў "Як узяць сеткавую інфраструктуру пад свой кантроль". Змест усіх артыкулаў цыклу і спасылкі можна знайсці .
Цалкам дапускаю, што існуе дастатковая колькасць кампаній, дзе просты сеткі ў адну гадзіну ці нават адзін дзень не з'яўляецца крытычным. Мне, нажаль ці на шчасце, не давялося працаваць у такіх месцах. Але, вядома, сеткі бываюць розныя, патрабаванні розныя, падыходы розныя, і ўсё ж, у тым ці іншым выглядзе, ніжэй прыведзены спіс у многіх выпадках будзе фактычна "маст-ду".
Такім чынам, зыходныя ўмовы.
Вы на новым месцы працы ці ў вас павышэнне ці вы вырашылі па-новаму зірнуць на свае абавязкі. Сетка кампаніі - гэта ваша зона адказнасці. Для вас шмат у чым гэта челлендж і новае, што некалькі апраўдвае настаўніцкі тон дадзенага артыкула :). Але, спадзяюся, што артыкул гэтак жа можа быць карысны і любому сеткаваму інжынеру.
Ваша першая стратэгічная мэта - навучыцца супрацьстаяць энтрапіі і ўтрымаць узровень які прадстаўляецца сэрвісу.
Многія апісаныя ніжэй задачы могуць быць вырашаны рознымі сродкамі. Я наўмысна не ўздымаю тэму тэхнічнай рэалізацыі, т.я. у прынцыпе часта не так важна, як вы вырашылі тую ці іншую задачу, а важна тое, як вы гэтым карыстаецеся і ці карыстаецеся наогул. Мала толку, напрыклад, ад вашай прафесійна выбудаванай сістэмы маніторынгу, калі вы туды не гледзіце і не рэагуеце на алерты.
Абсталяванне
Спачатку вам трэба зразумець, дзе найбольшыя рызыкі.
Ізноў-ткі можа быць па-рознаму. Дапускаю, што недзе, напрыклад, гэта будуць пытанні бяспекі, а недзе пытанні, звязаныя з бесперапыннасцю сэрвісу, а недзе, можа быць, нешта яшчэ. Чаму б не?
Дапусцім для пэўнасці, што гэта ўсё ж бесперапыннасць сэрвісу (так было ва ўсіх кампаніях, дзе працаваў я).
Тады трэба пачынаць з абсталявання. Вось спіс тэм, на якія трэба звярнуць увагу:
- класіфікацыя абсталявання па ступені крытычнасці
- рэзерваванне крытычнага абсталявання
- падтрымка, ліцэнзіі
Вы павінны прадумаць магчымыя варыянты паломак, асабліва з абсталяваннем, змешчаным на вяршыні вашай класіфікацыі крытычнасці. Звычайна, грэбуюць верагоднасцю падвойных праблем, інакш ваша рашэнне і падтрымка могуць стаць неапраўдана дарагімі, але ў выпадку сапраўды крытычных элементаў сеткі, выйсце са строю якіх можа істотна паўплываць на бізнэс, вы павінны падумаць і пра гэта.
Прыклад
Выкажам здагадку, мы гаворым аб каранёвым камутатары ў дата-цэнтры.
Т. к. мы дамовіліся, што бесперапыннасць сэрвісу з'яўляецца найболей важным крытэрам, то разумна забяспечыць «гарачае» рэзерваванне (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