Vir 'n beginner stelseladministrateur: hoe om orde uit chaos te skep

Ek is 'n FirstVDS-stelseladministrateur, en dit is die teks van die eerste inleidende lesing van my kortkursus oor die hulp van beginner-kollegas. Spesialiste wat onlangs by stelseladministrasie begin deelneem het, het 'n aantal van dieselfde probleme. Om oplossings te bied, het ek onderneem om hierdie reeks lesings te skryf. Sommige dinge daarin is spesifiek vir die aanbieding van tegniese ondersteuning, maar oor die algemeen kan dit nuttig wees, indien nie vir almal nie, dan vir baie. Ek het dus die lesingteks aangepas om hier te deel.

Dit maak nie saak wat jou posisie genoem word nie - wat saak maak, is dat jy in werklikheid by administrasie betrokke is. Kom ons begin dus met wat 'n stelseladministrateur moet doen. Sy hooftaak is om sake in orde te bring, orde te handhaaf en voor te berei vir toekomstige verhogings in orde. Sonder 'n stelseladministrateur word die bediener 'n gemors. Logs word nie geskryf nie, of die verkeerde dinge word daarin geskryf, hulpbronne word nie optimaal versprei nie, die skyf is gevul met allerhande vullis en die stelsel begin stadig doodgaan van soveel chaos. Rustig! Stelseladministrateurs in jou persoon begin probleme oplos en die gemors uitskakel!

Pilare van Stelseladministrasie

Voordat u egter probleme begin oplos, is dit die moeite werd om vertroud te raak met die vier hoofpilare van administrasie:

1. Dokumentasie
2. Sjabloon
3. Optimalisering
4. Outomatisering

Dit is die basiese beginsels. As jy nie jou werkvloei op hierdie beginsels bou nie, sal dit oneffektief, onproduktief wees en oor die algemeen min ooreenkomste met werklike administrasie hê. Kom ons kyk na elkeen afsonderlik.

Dokumentasie

Dokumentasie beteken nie om dokumentasie te lees nie (alhoewel jy nie daarsonder kan klaarkom nie), maar ook om dit in stand te hou.

Hoe om dokumentasie te hou:

• Het jy 'n nuwe probleem teëgekom wat jy nog nooit vantevore gesien het nie? Skryf die hoof simptome, metodes van diagnose en beginsels van eliminasie neer.
• Het jy vorendag gekom met 'n nuwe, elegante oplossing vir 'n algemene probleem? Skryf dit neer sodat jy dit nie 'n maand van nou af hoef te herontdek nie.
• Het hulle jou gehelp om 'n vraag uit te vind wat jy nie verstaan ​​nie? Skryf die hoofpunte en konsepte neer, teken vir jouself 'n diagram.

Die hoofgedagte: jy moet nie jou eie geheue heeltemal vertrou wanneer jy nuwe dinge bemeester en toepas nie.

In watter formaat jy dit sal doen, is aan jou: dit kan 'n stelsel met notas, 'n persoonlike blog, 'n tekslêer, 'n fisiese notaboek wees. Die belangrikste ding is dat u rekords aan die volgende vereistes voldoen:

1. Moenie te lank wees nie. Lig die hoofidees, metodes en gereedskap uit. As om 'n probleem te verstaan ​​vereis dat jy in die laevlakmeganika van geheuetoewysing in Linux duik, moenie die artikel waaruit jy dit geleer het, herskryf nie - verskaf 'n skakel daarna.
2. Die inskrywings moet vir jou duidelik wees. As die lyn race cond.lockup laat jou nie toe om dadelik te verstaan ​​wat jy met hierdie reël beskryf het nie - verduidelik. Goeie dokumentasie neem nie 'n halfuur om te verstaan ​​nie.
3. Soek is 'n baie goeie kenmerk. As jy blogplasings skryf, voeg merkers by; as dit in 'n fisiese notaboek is, plak klein post-its met beskrywings. Daar is min sin in dokumentasie as jy soveel tyd spandeer om 'n antwoord daarin te soek as wat jy sou spandeer om die vraag van nuuts af op te los.

Dit is hoe dokumentasie kan lyk: van primitiewe notas in 'n notaboek (prent hierbo), tot 'n volwaardige multi-gebruiker kennisbasis met etikette, soektog en alle moontlike geriewe (onder).

Nie net hoef jy nie twee keer na dieselfde antwoorde te soek nie, maar dokumentasie sal 'n groot hulp wees om nuwe onderwerpe aan te leer (notas!), sal jou spinnekop-sin verbeter (die vermoë om 'n komplekse probleem met een oppervlakkige blik te diagnoseer), en sal organisasie by jou aksies voeg. As die dokumentasie vir jou kollegas beskikbaar is, sal dit hulle toelaat om uit te vind wat en hoe jy daar opgestapel het wanneer jy nie daar is nie.

Sjabloon

Sjabloon is die skepping en gebruik van sjablone. Om die meeste tipiese probleme op te los, is dit die moeite werd om 'n spesifieke aksiesjabloon te skep. 'n Gestandaardiseerde volgorde van stappe moet gebruik word om die meeste probleme te diagnoseer. Wanneer jy iets herstel/geïnstalleer/geoptimaliseer het, moet die werkverrigting van hierdie iets nagegaan word met behulp van gestandaardiseerde kontrolelyste.

Sjabloon is die beste manier om jou werkvloei te organiseer. Deur standaardprosedures te gebruik om die mees algemene probleme op te los, kry jy baie oulike goed. Die gebruik van kontrolelyste sal jou byvoorbeeld toelaat om alle funksies wat belangrik is vir jou werk te diagnoseer en die diagnose van onbelangrike funksionaliteit weg te gooi. En gestandaardiseerde prosedures sal onnodige gooi verminder en die waarskynlikheid van foute verminder.

Die eerste belangrike punt is dat prosedures en kontrolelyste ook gedokumenteer moet word. As jy net op geheue staatmaak, kan jy 'n baie belangrike tjek of operasie mis en alles verwoes. Die tweede belangrike punt is dat alle sjabloonpraktyke gewysig kan en moet word indien die situasie dit vereis. Daar is geen ideale en absoluut universele sjablone nie. As daar 'n probleem is, maar 'n sjabloonkontrole het dit nie aan die lig gebring nie, beteken dit nie dat daar geen probleem is nie. Voordat u egter 'n paar onwaarskynlike hipotetiese probleme begin toets, is dit altyd die moeite werd om eers 'n vinnige sjabloontoets te doen.

Optimization

Optimization spreek vanself. Die werkproses moet soveel as moontlik geoptimaliseer word in terme van tyd en arbeidskoste. Daar is ontelbare opsies: leer sleutelbordkortpaaie, afkortings, gereelde uitdrukkings, beskikbare gereedskap. Soek meer praktiese gebruike van hierdie gereedskap. As jy 'n opdrag 100 keer per dag bel, ken dit toe aan 'n sleutelbordkortpad. As jy gereeld aan dieselfde bedieners moet koppel, skryf 'n alias in een woord wat jou daar sal verbind:

Maak jouself vertroud met die verskillende opsies wat beskikbaar is vir gereedskap - miskien is daar 'n geriefliker terminale kliënt, DE, knipbordbestuurder, blaaier, e-poskliënt, bedryfstelsel. Vind uit watter gereedskap jou kollegas en vriende gebruik - miskien kies hulle dit vir 'n rede. Sodra jy die gereedskap het, leer hoe om dit te gebruik: leer die sleutels, afkortings, wenke en truuks.

Maak optimaal gebruik van standaard gereedskap - coreutils, vim, gereelde uitdrukkings, bash. Vir die laaste drie is daar 'n groot aantal wonderlike handleidings en dokumentasie. Met hul hulp kan jy vinnig gaan van die toestand van "Ek voel soos 'n aap wat neute met 'n skootrekenaar kraak" na "Ek is 'n aap wat 'n skootrekenaar gebruik om vir my 'n neutkraker te bestel."

outomatisering

outomatisering sal moeilike bedrywighede van ons moeë hande na die onvermoeide hande van outomatisering oordra. As een of ander standaardprosedure uitgevoer word in vyf opdragte van dieselfde tipe, hoekom dan nie al hierdie opdragte in een lêer toevou en een opdrag oproep wat hierdie lêer aflaai en uitvoer nie?

Outomatisering self is 80% om jou eie gereedskap te skryf en te optimaliseer (en nog 20% ​​probeer om dit te laat werk soos dit moet). Dit kan net 'n gevorderde eenlyn of 'n groot almagtige hulpmiddel met 'n webkoppelvlak en API wees. Die hoofkriterium hier is dat die skep van 'n instrument nie meer tyd en moeite moet neem as die hoeveelheid tyd en moeite wat die instrument jou sal spaar nie. As jy vyf uur spandeer om 'n draaiboek te skryf wat jy nooit weer sal nodig hê nie, vir 'n taak wat jou 'n uur of twee sou neem om sonder die draaiboek op te los, is dit 'n baie swak werkvloeioptimalisering. U kan slegs vyf uur spandeer om 'n instrument te skep as die aantal, tipe take en tyd dit toelaat, wat nie dikwels die geval is nie.

Outomatisering beteken nie noodwendig die skryf van volwaardige skrifte nie. Om byvoorbeeld 'n klomp voorwerpe van dieselfde tipe uit 'n lys te skep, is al wat jy nodig het 'n slim eenlyn wat outomaties sal doen wat jy met die hand sal doen, tussen vensters wissel, met hope copy-paste.

Eintlik, as jy die administrasieproses op hierdie vier pilare bou, kan jy vinnig jou doeltreffendheid, produktiwiteit en kwalifikasies verhoog. Hierdie lys moet egter aangevul word met nog een item, waarsonder werk in IT amper onmoontlik is - selfonderrig.

Stelsel administrateur selfopvoeding

Om selfs 'n bietjie bekwaam op hierdie gebied te wees, moet jy voortdurend nuwe dinge leer en leer. As jy nie die geringste begeerte het om die onbekende in die oë te kyk en dit uit te vind nie, sal jy baie vinnig vashaak. Allerlei nuwe oplossings, tegnologieë en metodes verskyn voortdurend in IT, en as jy dit nie ten minste oppervlakkig bestudeer nie, is jy op pad na mislukking. Baie gebiede van inligtingstegnologie staan ​​op 'n baie komplekse en lywige basis. Byvoorbeeld, netwerkwerking. Netwerke en die internet is oral, jy kom hulle elke dag teë, maar sodra jy in die tegnologie daaragter delf, sal jy 'n groot en baie komplekse dissipline ontdek, waarvan die studie nooit 'n wandeling in die park is nie.

Ek het nie hierdie item in die lys ingesluit nie, want dit is die sleutel vir IT in die algemeen, en nie net vir stelseladministrasie nie. Natuurlik sal jy nie dadelik alles kan leer nie - jy het eenvoudig nie fisies genoeg tyd nie. Daarom, wanneer jy jouself opvoed, moet jy die nodige vlakke van abstraksie onthou.

Jy hoef nie dadelik te leer hoe die interne geheuebestuur van elke individuele nutsprogram werk en hoe dit met die Linux-geheuebestuur in wisselwerking tree nie, maar dit is goed om skematies te weet wat RAM is en hoekom dit nodig is. U hoef nie te weet hoe TCP- en UDP-opskrifte struktureel verskil nie, maar dit sal 'n goeie idee wees om die basiese verskille in hoe die protokolle werk te verstaan. Jy hoef nie te leer wat seinverswakking in optika is nie, maar dit sal lekker wees om te weet hoekom werklike verliese altyd oor nodusse oorgeërf word. Daar is niks verkeerd daarmee om te weet hoe sekere elemente op 'n sekere vlak van abstraksie werk nie en om nie noodwendig absoluut alle vlakke te verstaan ​​wanneer daar geen abstraksie is nie (jy sal sommer mal word).

In jou veld is dit egter nie baie goed om op die vlak van abstraksie te dink "wel, dit is 'n ding wat jou toelaat om webwerwe te vertoon". Die volgende lesings sal gewy word aan 'n oorsig van die hoofareas wat 'n stelseladministrateur moet hanteer wanneer hy op laer vlakke van abstraksie werk. Ek sal probeer om die hoeveelheid kennis wat hersien word te beperk tot 'n minimum vlak van abstraksie.

10 gebooie van stelseladministrasie

So, ons het die vier hoofpilare en grondslag geleer. Kan ons probleme begin oplos? Nog nie. Voordat jy dit doen, is dit raadsaam om jouself te vergewis van die sogenaamde “beste praktyke” en reëls van goeie maniere. Sonder hulle sal jy waarskynlik meer skade doen as goed. So, kom ons begin:

1. Sommige van my kollegas glo dat die heel eerste reël is "doen geen kwaad nie." Maar ek is geneig om nie saam te stem nie. As jy probeer om nie skade aan te doen nie, kan jy niks doen nie - te veel aksies is potensieel vernietigend. Ek dink die belangrikste reël is - "maak 'n rugsteun". Selfs as jy skade aanrig, kan jy altyd terugrol en alles sal nie so erg wees nie.

   U moet altyd rugsteun wanneer tyd en plek dit toelaat. Jy moet rugsteun wat jy sal verander en wat jy kan verloor as gevolg van 'n potensieel vernietigende aksie. Dit is raadsaam om die rugsteun na te gaan vir integriteit en die teenwoordigheid van alle nodige data. Die rugsteun moet nie onmiddellik uitgevee word nadat jy alles nagegaan het nie, tensy jy skyfspasie moet vrymaak. As die ligging dit vereis, rugsteun dit na jou persoonlike bediener en vee dit na 'n week uit.

2. Die tweede belangrikste reël (wat ek self dikwels oortree) is "moenie wegkruip nie". As jy 'n rugsteun gemaak het, skryf waar, sodat jou kollegas nie daarna hoef te soek nie. As jy 'n paar nie-vanselfsprekende of komplekse aksies gedoen het, skryf dit neer: jy sal huis toe gaan, en die probleem kan herhaal word of vir iemand anders ontstaan, en jou oplossing sal gevind word deur sleutelwoorde te gebruik. Selfs as jy iets doen wat jy goed ken, mag jou kollegas nie.
3. Die derde reël hoef nie verduidelik te word nie: “Moet nooit iets doen waarvan jy die gevolge nie weet, voorstel of verstaan ​​nie”. Moenie opdragte van die internet af kopieer as jy nie weet wat hulle doen nie, bel man en ontleed dit eers. Moenie klaargemaakte oplossings gebruik as jy nie kan verstaan ​​wat hulle doen nie. Hou die uitvoering van verduisterde kode tot 'n absolute minimum. As jy nie tyd het om dit uit te vind nie, dan doen jy iets verkeerd en jy moet die volgende punt lees.
4. "Toets". Nuwe skrifte, gereedskap, eenlyners en opdragte moet in 'n beheerde omgewing getoets word, nie op die kliëntmasjien nie, as daar selfs minimale potensiaal vir vernietigende aksies is. Selfs al het jy alles gerugsteun (en jy het), is stilstand nie die coolste ding nie. Skep 'n aparte bediener/virtuele/chroot hiervoor en toets daar. Is enigiets stukkend? Dan kan jy dit op "combat" begin.

   
   

5. "Beheer". Minimaliseer alle bedrywighede wat jy nie beheer nie. Een pakketafhanklikheidskromme kan die helfte van die stelsel afsleep, en die -y-vlag wat vir yum remove gestel is, gee jou die geleentheid om jou stelselherstelvaardighede van nuuts af te oefen. As die aksie geen onbeheerde alternatiewe het nie, is die volgende punt 'n klaargemaakte rugsteun.
6. "Tjek". Kontroleer die gevolge van jou optrede en of jy moet terugrol na 'n rugsteun. Kyk of die probleem werklik opgelos is. Kontroleer of die fout gereproduseer word en onder watter omstandighede. Kyk wat jy kan breek met jou optrede. Dit is onnodig om in ons werk te vertrou, maar om nooit na te gaan nie.
7. "Kommunikeer". As jy nie die probleem kan oplos nie, vra jou kollegas of hulle dit teëgekom het. As jy 'n omstrede besluit wil toepas, vind die mening van jou kollegas uit. Miskien sal hulle 'n beter oplossing bied. As jy nie selfversekerd is in jou optrede nie, bespreek dit met jou kollegas. Selfs al is dit jou gebied van kundigheid, kan 'n nuwe blik op die situasie baie verduidelik. Moenie skaam wees oor jou eie onkunde nie. Dit is beter om 'n dom vraag te vra, soos 'n dwaas te lyk en 'n antwoord te kry, as om nie die vraag te vra nie, nie 'n antwoord te kry en uiteindelik 'n dwaas te wees nie.
8. “Moenie hulp onredelik weier nie”. Hierdie punt is die omgekeerde van die vorige een. As jy 'n dom vraag gevra word, verduidelik en verduidelik. Hulle vra vir die onmoontlike – verduidelik dat dit onmoontlik is en hoekom, bied alternatiewe. As jy nie tyd het nie (jy het regtig nie die tyd nie, nie die begeerte nie) - sê dat jy 'n dringende vraag het, baie werk, maar jy sal dit later uitsorteer. As kollegas nie dringende take het nie, bied aan om hulle te kontak en die vraag te delegeer.
9. "Gee terugvoering". Het een van jou kollegas 'n nuwe tegniek of 'n nuwe draaiboek begin gebruik, en ondervind jy negatiewe gevolge van hierdie besluit? Rapporteer dit. Miskien kan die probleem opgelos word in drie reëls kode of vyf minute om die tegniek te verfyn. Het jy 'n fout in jou sagteware teëgekom? Rapporteer 'n fout. As dit reproduseerbaar is of nie gereproduseer hoef te word nie, sal dit heel waarskynlik reggestel word. Stem jou wense, voorstelle en konstruktiewe kritiek uit, en bring vrae vir bespreking as dit relevant lyk.
10. "Vra vir terugvoer". Ons is almal onvolmaak, net soos ons besluite, en die beste manier om die korrektheid van jou besluit te toets, is om dit vir bespreking te bring. As jy iets vir 'n kliënt geoptimaliseer het, vra hulle om die werk te monitor; miskien is die bottelnek in die stelsel nie waar jy gesoek het nie. Jy het 'n hulpskrif geskryf - wys dit vir jou kollegas, miskien sal hulle 'n manier vind om dit te verbeter.

As jy voortdurend hierdie praktyke in jou werk toepas, sal die meeste van die probleme ophou om probleme te wees: jy sal nie net die getal van jou eie foute en namaaksels tot 'n minimum verminder nie, maar jy sal ook die geleentheid hê om foute reg te stel (in die vorm van rugsteun en kollegas wat jou sal aanraai om te rugsteun). Verder - slegs tegniese besonderhede, waarin, soos ons weet, die duiwel lê.

Die belangrikste gereedskap waarmee jy meer as 50% van die tyd sal moet werk, is grep en vim. Wat kan eenvoudiger wees? Tekssoektog en teksredigering. Beide grep en vim is egter kragtige multi-nutsmiddels wat jou toelaat om teks doeltreffend te soek en te wysig. As een of ander Windows-notaboek jou toelaat om eenvoudig 'n reël te skryf/vee, dan kan jy in vim amper enigiets met teks doen. As jy my nie glo nie, bel die vimtutor-opdrag vanaf die terminale en begin leer. Wat grep betref, is die hoofkrag daarvan in gereelde uitdrukkings. Ja, die instrument self laat jou toe om soekvoorwaardes en uitvoerdata redelik buigsaam te stel, maar sonder RegExp maak dit nie veel sin nie. En jy moet gereelde uitdrukkings ken! Ten minste op 'n basiese vlak. Om mee te begin, sal ek jou aanraai om hierna te kyk video, dit dek die basiese beginsels van gereelde uitdrukkings en hul gebruik in samewerking met grep. O ja, as jy dit met vim kombineer, kry jy die ULTIMATE POWER-vermoë om sulke dinge met teks te doen dat jy hulle met 18+ ikone moet etiketteer.

Van die oorblywende 50% kom 40% van die coreutils-gereedskapstel. Vir coreutils kan jy kyk na die lys by Wikipedia, en die handleiding vir die hele lys is op die webwerf GNU. Wat nie in hierdie stel gedek word nie, is in die nutsprogramme POSIX. Jy hoef nie al die sleutels uit jou kop te leer nie, maar dit is nuttig om ten minste min of meer te weet wat die basiese gereedskap kan doen. Jy hoef nie die wiel van krukke weer uit te vind nie. Ek moes op een of ander manier lynbreuke vervang met spasies in die uitset van een of ander hulpprogram, en my siek brein het geboorte gegee aan 'n konstruksie soos sed ':a;N;$!ba;s/n/ /g', het 'n kollega gekom en my met 'n besem van die konsole weggejaag, en toe die probleem opgelos deur te skryf tr 'n' ' '.

Ek sal jou aanraai om te onthou wat elke individuele instrument doen en die sleutels tot die mees gebruikte opdragte; vir alles anders is daar 'n mens. Skakel gerus man as jy enige twyfel het. En maak seker dat jy die man self lees—dit bevat belangrike inligting oor wat jy sal vind.

Deur hierdie instrumente te ken, sal jy 'n beduidende deel van die probleme wat jy in die praktyk sal teëkom, effektief kan oplos. In die volgende lesings sal ons kyk na wanneer om hierdie nutsmiddels en die raamwerke te gebruik vir die onderliggende dienste en toepassings waarop hulle van toepassing is.

FirstVDS-stelseladministrateur Kirill Tsvetkov was saam met jou.

Bron: will.com