🥇Пачынальнаму сісадміну: як з хаосу зрабіць парадак

Я сістэмны адміністратар FirstVDS, і гэта - тэкст першай уступнай лекцыі з майго кароткага курсу дапамогі пачаткоўцам калегам. Спецыялісты, якія нядаўна пачалі займацца сістэмным адміністраваннем, сутыкаюцца з шэрагам адных і тых жа праблем. Каб прапанаваць рашэнні, я ўзяўся напісаць гэты цыкл лекцый. Некаторыя рэчы ў ім спецыфічныя для тэхнічнай падтрымкі хостынгу, але ў цэлым, могуць аказацца карыснымі калі не для ўсіх, то для многіх. Таму я адаптаваў тэкст лекцыі, каб падзяліцца тут.

Не мае значэння, як называецца ваша пасада - важна, што па факце вы займаецеся адміністраваннем. Таму пачнем з таго, чым павінен займацца сістэмны адміністратар. Асноўная яго задача - гэта прывядзенне ў парадак, падтрыманне парадку і падрыхтоўка да будучых павелічэнняў парадку. Без сістэмнага адміністратара на серверы пачынаецца бардак. Логі не пішуцца, ці ў іх пішацца не тое, рэсурсы размяркоўваюцца неаптымальна, дыск запаўняецца разнастайным смеццем і сістэма пачынае павольна загінацца ад такой колькасці хаосу. Спакойна! Сістэмныя адміністратары ў вашай асобе прыступаюць да рашэння праблем і ўхіленню бардака!

Слупы сістэмнага адміністравання

Аднак перш, чым прыступаць да вырашэння праблем, варта пазнаёміцца з чатырма асноўнымі слупамі адміністравання:

Дакументацыяй
Шабланізацыяй
Аптымізацыяй
Аўтаматызацыяй

Гэта аснова асноў. Калі не будаваць свой працоўны працэс на гэтых прынцыпах, ён будзе неэфектыўным, непрадуктыўным і ўвогуле мала падобным да сапраўднага адміністравання. Давайце разбяромся з кожным асобна.

Дакументацыя

Дакументацыя мае на ўвазе пад сабой не чытанне дакументацыі (хоць без гэтага нікуды), але і вядзенне.

Як весці дакументацыю:

Сутыкнуліся з новай праблемай, якую да гэтага не бачылі ніколі? Запішыце асноўныя сімптомы, спосабы дыягностыкі і прынцыпы ўхілення.
Прыдумалі новае элегантнае рашэнне тыпавой праблемы? Запішыце яго, каб вам не прыйшлося вынаходзіць яго зноўку праз месяц.
Вам памаглі разабрацца з пытаннем, у якім вы нічога не разумелі? Запішыце асноўныя тэзісы і канцэпцыі, намалюйце сабе схему.

Асноўная ідэя: не варта цалкам давярацца ўласнай памяці пры засваенні і ўжыванні новага.

У якім фармаце вы гэта будзеце рабіць, залежыць толькі ад вас: гэта можа быць сістэма з нататкамі, асабісты блог, тэкставы файл, фізічны нататнік. Галоўнае, каб вашыя запісы адказвалі наступным патрабаванням:

Не быць залішне доўгімі. Выдзяляйце асноўныя ідэі, метады і сродкі. Калі разуменне праблемы патрабуе нырнуць у нізкаўзроўневую механіку працы вылучэння памяці ў Linux, не перапісвайце артыкул, з якой вы яе пазналі - дайце на яе спасылку.
Запісы павінны быць зразумелымі для вас. Калі радок race cond.lockup не дазваляе вам адразу зразумець, што вы гэтым радком апісалі - растлумачце. У добрай дакументацыі не трэба разбірацца па паўгадзіны.
Пошук - вельмі добрая фішка. Калі вы вядзеце запісы ў блогу, дадавайце тэгі; калі ў фізічным нататніку - прыляпляйце маленькія post-it з апісаннямі. Няма асаблівага сэнсу ў дакументацыі, калі вы на пошук адказу ў ёй марнуеце столькі ж часу, колькі патрацілі б на вырашэнне пытання з нуля.

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

Вам не толькі не прыйдзецца шукаць адны і тыя ж адказы двойчы: дакументаванне будзе выдатнай падмогай у вывучэнні новых тэм (канспекты ж!), прапампуе ваша павуковае нюх (здольнасць дыягнаставаць складаную праблему, кінуўшы адзін павярхоўны погляд), дадасць арганізаванасці ў вашы дзеянні. Калі дакументацыя будзе даступная вашым калегам, то дазволіць ім разабрацца, што і як вы тамака нагарадзілі, калі вас не будзе на месцы.

Шабланізацыя

Шабланізацыя - Гэта стварэнне і выкарыстанне шаблонаў. Для рашэння большасці тыпавых пытанняў варта стварыць вызначаны шаблон дзеянняў. Для дыягностыкі большасці праблем варта выкарыстоўваць стандартызаваную паслядоўнасць дзеянняў. Калі вы нешта паправілі/усталявалі/аптымізавалі, працаздольнасць гэтага чагосьці варта правяраць па стандартызаваных чэк-лістах.

Шабланізацыя - лепшы спосаб арганізацыі працоўнага працэсу. Выкарыстоўваючы тыпавыя працэдуры для вырашэння найбольш частых праблем, вы атрымліваеце шмат усяго класнага. Напрыклад, выкарыстанне чэк-лістоў дазволіць вам дыягнаставаць усе важныя для працы функцыі і адкінуць дыягностыку малаважнай функцыянальнасці. А стандартызаваныя працэдуры звядуць да мінімуму непатрэбныя кіданні і знізяць верагоднасць памылкі.

Першым важным момантам з'яўляецца тое, што працэдуры і чэк-лісты таксама трэба дакументаваць. Калі проста спадзявацца на памяць, можна прапусціць якую-небудзь рэальна важную праверку ці аперацыю і ўсё разваліць. Другі важны момант - усе шаблонныя практыкі можна і трэба мадыфікаваць, калі гэтага патрабуе сітуацыя. Ідэальных і абсалютна ўніверсальных шаблонаў няма. Калі праблема ёсць, а шаблонная праверка яе не выявіла - гэта не значыць, што праблемы няма. Аднак перш, чым брацца за праверку нейкіх малаверагодных гіпатэтычных праблем, заўсёды варта спачатку зрабіць хуткую шаблонную праверку.

Аптымізацыя

Аптымізацыя кажа сама за сябе. Рабочы працэс трэба максімальна аптымізаваць у плане час- і працазатрат. Тут варыянтаў незлічонае мноства: вывучыце гарачыя клавішы, скарачэнні, рэгулярныя выразы, даступныя прылады. Шукайце варыянты больш практычнага выкарыстання гэтых прылад. Калі вы 100 разоў на дзень выклікаеце каманду, павесьце яе на клавіятурнае скарачэнне. Калі вам трэба рэгулярна падлучацца да адных і тых жа сервераў, запішыце alias у адно слова, які будзе вас туды падлучаць:

Азнаёмцеся з рознымі варыянтамі даступных інструментаў - магчыма, ёсць зручнейшы тэрмінальны кліент, DE, менеджэр буфера абмену, браўзэр, паштовы кліент, аперацыйная сістэма. Даведайцеся, якімі інструментамі карыстаюцца вашыя калегі і знаёмыя - можа, яны выбіраюць іх не проста так. Пасля таго, як вы падбераце прылады, навучыцеся іх ужываць: вывучыце ключы, скарачэнні, tips and tricks.

Аптымальна выкарыстоўвайце стандартныя прылады - coreutils, vim, рэгулярныя выразы, bash. Для апошніх трох ёсць велізарная колькасць выдатных мануалаў і дакументацыя. З іх дапамогай можна даволі хутка перайсці ад стану "я адчуваю сябе малпай, якая коле арэхі наўтбукам - да "я малпа, якая выкарыстоўвае ноўтбук, каб замовіць сабе арэхакол".

Аўтаматызацыя

Аўтаматызацыя перанясе цяжкія аперацыі з нашых стомленых рук у нястомныя рукі аўтаматыкі. Калі нейкая стандартная працэдура выконваецца ў пятак аднатыпных каманд, то чаму б не абгарнуць усе гэтыя каманды ў адзін файлік і не клікаць адну каманду, якая гэты файлік пампуе і выконвае?

Уласна аўтаматызацыя на 80% складаецца з напісання і аптымізацыі сваіх уласных прылад (і яшчэ на 20% са спробаў прымусіць іх працаваць як трэба). Гэта можа быць проста прасунуты аднарадкоўнік ці ж велізарная ўсемагутная тулза з вэб-інтэрфейсам і API. Галоўны крытэр тут - стварэнне інструмента павінна займаць не больш часу і намаганняў, чым колькасць часу і намаганняў, якое вам гэты інструмент зэканоміць. Калі вы пяць гадзін пішаце скрыпт, які вам больш ніколі не спатрэбіцца, для задачы, на рашэнне якой у вас без скрыпту сышоў бы гадзіну-другую - гэта вельмі дрэнная аптымізацыя працоўнага працэсу. Можна выдаткаваць XNUMX:XNUMX на стварэнне інструмента, толькі калі колькасць, тып задач і час гэта дазваляюць, што бывае нячаста.

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

Уласна, калі пабудаваць працэс адміністравання на гэтых чатырох слупах, то можна даволі хутка павысіць сваю эфектыўнасць, прадуктыўнасць і кваліфікацыю. Аднак гэты спіс трэба дапоўніць яшчэ адным пунктам, без якога праца ў IT практычна немагчымая – самаадукацыяй.

Самаадукацыя сісадміна

Каб быць у гэтай сферы хоць крыху кампетэнтнымі, трэба пастаянна вучыцца і даведвацца пра новае. Калі ў вас няма ні найменшага жадання сутыкацца з невядомым і разбірацца, вы вельмі хутка «просядзеце». У IT пастаянна з'яўляюцца разнастайныя новыя рашэнні, тэхналогіі і метады, і калі вы не вывучаеце іх хаця б павярхоўна – вы на шляху да пройгрышу. Многія вобласці інфармацыйных тэхналогій стаяць на вельмі складаным і аб'ёмным базісе. Напрыклад, праца сеткі. Сеткі і інтэрнэт ёсць усюды, вы сутыкаецеся з імі штодня, але варта капнуць у тэхналогіі, якія стаяць за імі, вы выявіце велізарную і вельмі складаную дысцыпліну, вывучэнне якой - ні разу не шпацыр у парку.

Я не стаў уключаць гэты пункт у спіс, таму што ён - ключавы для IT увогуле, а не толькі для сістэмнага адміністравання. Натуральна, вывучыць абсалютна ўсё і адразу не атрымаецца - у вас проста фізічна не хопіць часу. Таму пры самаадукацыі варта памятаць аб неабходных узроўнях абстракцыі.

Вам неабавязкова адразу вучыць, як працуе ўнутраны мэнэджмент памяці ў кожнай асобна ўзятай утыліты, і як ён узаемадзейнічае з мэнэджментам памяці Linux, але вось што аператыўная памяць з сябе ўяўляе схематычна, і навошта яна патрэбна, шляхта нядрэнна. Вам неабавязкова ведаць, як структурна адрозніваюцца загалоўкі ў TCP і UDP, але было б нядрэнна разумець асноўныя адрозненні пратаколаў у працы. Вам не трэба вывучаць, што з сябе ўяўляюць згасанні сігналу ў оптыцы, але было б нядрэнна ведаць, чаму сапраўдныя страты заўсёды ўспадкоўваюцца па вузлах. Няма нічога дрэннага ў тым, каб ведаць як працуюць пэўныя элементы на пэўным узроўні абстракцыі і неабавязкова разбіраць абсалютна ўсе ўзроўні, калі абстракцыі няма наогул (вы проста звар'яцецеся).

Аднак у сваёй вобласці разважаць на ўзроўні абстракцыі "ну гэта такая штука, якая дазваляе паказваць сайтыкі" – не вельмі добра. Наступныя лекцыі будуць прысвечаны агляду асноўных абласцей, з якімі сістэмнаму адміністратару даводзіцца сутыкацца ў працы на ніжэйшых узроўнях абстракцыі. Я пастараюся абмежаваць колькасць аглядаемых ведаў мінімальным узроўнем абстракцыі.

10 запаведзяў сістэмнага адміністравання

Такім чынам, мы засвоілі чатыры асноўныя слупы і падмурак. Ці можна пачынаць вырашаць праблемы? Яшчэ не. Перад гэтым пажадана азнаёміцца з так званымі "best practices" і правіламі добрага тону. Без іх ёсць верагоднасць, што вы прынесяце больш шкоды, чым карысці. Такім чынам, пачнем:

Некаторыя мае калегі лічаць, што самае першае правіла - "не нашкодзь". Але я схільны не пагадзіцца. Калі спрабуеш не нашкодзіць, то і зрабіць нічога не можаш - занадта шмат дзеянняў патэнцыйна дэструктыўныя. Самым важным правілам я лічу - зрабі бэкап. Нават калі нашкодзіш, заўжды можна будзе адкаціцца, і ўсё будзе ўжо не так дрэнна.
Бэкапіць трэба заўсёды, калі час і месца дазваляюць гэта. Бэкапіць трэба тое, што вы будзеце мяняць і тое, што вы рызыкуеце страціць пры патэнцыйна дэструктыўным дзеянні. Бэкап пажадана праверыць на цэласнасць і наяўнасць усіх патрэбных дадзеных. Бэкап не варта выдаляць адразу пасля таго, як вы ўсё праверылі, калі не патрабуецца вызваліць месца на дыску. Калі месца патрабуе - забэкапце на ваш асабісты сервер і выдаляйце праз тыдзень.
Другое па важнасці правіла (якое я сам часта парушаю) «не хавай». Калі вы зрабілі бэкап, напішыце - куды, каб вашым калегам не даводзілася яго шукаць. Калі вы зрабілі нейкія невідавочныя ці складаныя дзеянні, запішыце: вы сыдзеце дадому, а праблема можа паўтарыцца ці ўзнікнуць у кагосьці іншага і ваша рашэнне знойдуць па ключавых словах. Нават калі вы робіце нешта, што добра ведаеце, гэтага могуць не ведаць вашыя калегі.
Трэцяе правіла тлумачыць не трэба: "ніколі не рабі таго, наступствы чаго ты не ведаеш, не ўяўляеш ці не разумееш". Не капіюй каманды з інтэрнэту, калі не ведаеш, што яны робяць, пакліч man і распарссі спачатку. Не прымяняй гатовыя рашэнні, калі не можаш зразумець, што яны робяць. Звядзі да абсалютнага мінімуму выкананне обфусцированного кода. Калі часу разбірацца няма - тыя вы нешта робіце не так і вам варта азнаёміцца з наступным пунктам.
«Тэстуй». Новыя скрыпты, прылады, аднарадкоўнікі і каманды варта правяраць у кантраляваным асяроддзі, а не на кліенцкай машыне, калі там ёсць хаця б мінімальны патэнцыял да дэструктыўных дзеянняў. Нават калі вы ўсё забэкапілі (а вы гэта зрабілі), даунтайм - не самая класная справа. Завядзіце для гэтай справы асобны сервак/віртуалку/chroot і тэсціруйце там. Нічога не зламалася? Тады можна запускаць на "баявым".
«Кантралюй». Звядзіце да мінімуму ўсе аперацыі, якія вы не кантралюеце. Адна крывая залежнасць у пакета можа сцягнуць за сабой палову сістэмы, а выстаўлены для yum remove сцяг -y, дае вам магчымасць патрэніраваць свае навыкі ўзнаўлення сістэмы з нуля. Калі ў дзеяння няма бескантрольных альтэрнатыў - наступны пункт і гатовы бэкап.
«Правярай». Правярайце наступствы сваіх дзеянняў і ці трэба адкаціцца на бэкап. Правярайце, ці сапраўды праблема вырашылася. Правярайце, ці прайграваецца памылка і пры якіх умовах. Правярайце, што вы можаце разламаць сваімі дзеяннямі. Давяраць у нашай працы - лішняе, а вось правяраць - ніколі.
«Маўчыся». Калі не атрымоўваецца вырашыць праблему, спытаеце ў калегаў, ці не сутыкаліся яны з такім. Жадаеце прымяніць спрэчнае рашэнне - даведайцеся меркаванне калегаў. Магчыма яны прапануюць рашэнне лепш. Няма ўпэўненасці ў сваіх дзеяннях - абмяркуйце іх з калегамі. Нават калі гэта ваша экспертная вобласць, свежы погляд на сітуацыю можа шмат што растлумачыць. Не саромейцеся ўласнага няведання. Лепш задаць дурное пытанне, здацца дурнем і атрымаць на яго адказ, чым не задаваць гэтае пытанне, не атрымаць адказ і застацца ў дурнях.
«Не адмаўляй у дапамозе беспадстаўна». Гэты пункт - адваротны бок папярэдняга. Калі вам задалі дурное пытанне - растлумачыце і растлумачце. Просяць невыканальнага - растлумачце, што яно невыканальна і чаму, прапануйце альтэрнатывы. Калі няма часу (рэальна няма часу, а не жадання) - скажыце, што ў вас ёсць тэрміновае пытанне вялікі аб'ём працы, але вы разбярэцеся пазней. Калі ў калегаў няма тэрміновых задач, прапануйце звярнуцца да іх і дэлегуйце пытанне.
«Давай фідбэк». Хтосьці з калегаў пачаў ужываць новую методыку ці новы скрыпт, а вы сустракаецеся з негатыўнымі наступствамі гэтага рашэння? Паведаміце пра гэта. Магчыма, праблема вырашаецца ў тры радкі кода ці пяць хвілін дапрацоўкі методыкі. Наткнуліся на баг у ПЗ? Паведаміце пра бага. Калі ён прайграваецца ці яго няма неабходнасці прайграваць, яго, хутчэй за ўсё, пафіксуюць. Агучвайце пажаданні, прапановы і канструктыўную крытыку, выносьце пытанні на абмеркаванне, калі здаецца, што яны актуальныя.
«Прасі фідбэка». Мы ўсе неідэальныя, як і нашы рашэнні, а лепшы спосаб праверыць правільнасць свайго рашэння - вынесці яго на абмеркаванне. Зааптымізавалі нешта ў кліента - папытаеце прасачыць за працай, можа «бутэлькавае рыльца» у сістэмы не там, дзе вы шукалі. Напісалі скрыптык-дапамагайку – пакажыце калегам, можа яны знойдуць спосаб яго палепшыць.

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

Асноўныя прылады, з якімі вам давядзецца працаваць больш за 50% часу - grep і vim. Што можа быць прасцей? Пошук па тэксце і рэдагаванне тэксту. Аднак і grep, і vim - наймагутныя шматфункцыянальныя мультытулы, якія дазваляюць шукаць і рэдагаваць тэкст эфектыўна. Калі які-небудзь віндовы notepad дазволіць вам проста напісаць/выдаліць радок, то ў vim’е можна рабіць з тэкстам амаль што заўгодна. Не верыце - выклічце з тэрмінала каманду vimtutor і пачынайце вучыць. Што ж тычыцца grep - асноўная яго сіла ў рэгулярных выразах. Так, сама прылада дазваляе даволі гнутка задаваць умовы пошуку і выводныя дадзеныя, але без RegExp гэта адмысловага сэнсу не мае. І рэгулярныя выразы ведаць трэба! Хаця б на базавым узроўні. Для пачатку я б параіў вам паглядзець вось гэта відэа, у ім разбіраюцца асновы асноў рэгулярных выразаў і іх ужывання сумесна з grep. Ах так, пры сумяшчэнні іх з vim, вы атрымліваеце ULTIMATE POWER магчымасць рабіць з тэкстам такія рэчы, што іх даводзіцца абчапляць значкамі 18+.

З пакінутых 50%, 40% прыпадаюць на пакет інструментаў coreutils. Для coreutils спіс вы можаце паглядзець у вікіпедыі, а мануал да ўсяго спісу - на сайце GNU. Што не пакрыта гэтым наборам, ёсць ва ўтылітах POSIX. Неабавязкова вучыць гэта з усімі ключамі на памяць, але хаця б прыкладна ведаць, што могуць асноўныя інструменты - карысна. Не прыйдзецца вынаходзіць ровар з мыліц. Мне неяк трэба было замяніць пераносы радка на прабелы ў выснове ад нейкай утыліты, і хворы мозг нарадзіў канструкцыю выгляду sed ':a;N;$!ba;s/n/ /g', які надышоў калега адагнаў мяне венікам ад кансолі, а потым вырашыў задачу, напісаўшы tr 'n' ' '.

Я б параіў запомніць, што прыкладна выконвае кожная асобная тулза і ключыкі да самых часта выкарыстоўваных каманд, для ўсяго астатняга ёсць man. Не саромейцеся клікаць man, калі вы ў чымсьці сумняваецеся. І абавязкова прачытайце man на сам man - ён змяшчае важную інфармацыю аб тым, што вы знойдзеце.

Ведаючы гэтыя прылады, вы зможаце эфектыўна вырашыць значную частку задач, з якімі сутыкнецеся на практыку. У наступных лекцыях мы разгледзім, калі прымяняць гэтыя інструменты і структуры асноўных службаў і прыкладанняў, да якіх яны прымяняюцца.

З вамі быў сістэмны адміністратар FirstVDS Кірыл Цвяткоў.

Крыніца: habr.com

Пачаткоўцу сісадміну: як з хаосу зрабіць парадак