Ik bin in systeembehearder fan FirstVDS, en dit is de tekst fan 'e earste ynliedende lêzing fan myn koarte kursus oer it helpen fan begjinnende kollega's. Spesjalisten dy't koartlyn begon te dwaan oan systeemadministraasje hawwe in oantal deselde problemen te krijen. Om oplossingen oan te bieden, haw ik my ûndernommen om dizze rige lêzingen te skriuwen. Guon dingen dêryn binne spesifyk foar hosting fan technyske stipe, mar yn 't algemien kinne se nuttich wêze, as net foar elkenien, dan foar in protte. Dat ik haw de lêzingtekst oanpast om hjir te dielen.
It makket net út hoe't jo posysje hjit - wat fan belang is dat jo yn feite belutsen binne by administraasje. Litte wy dêrom begjinne mei wat in systeembehearder moat dwaan. Syn wichtichste taak is om dingen yn oarder te bringen, oarder te hâlden en ta te rieden op takomstige ferhegings yn oarder. Sûnder in systeembehearder wurdt de tsjinner in puinhoop. Logboeken wurde net skreaun, of de ferkearde dingen binne deryn skreaun, middels wurde net optimaal ferdield, de skiif sit fol mei allerhanne jiskefet en it systeem begjint stadichoan te stjerren fan safolle gaos. Rêstich! Systeembehearders yn jo persoan begjinne problemen op te lossen en de puinhoop te eliminearjen!
Pylders fan System Administration
Foardat jo lykwols begjinne mei it oplossen fan problemen, is it de muoite wurdich om bekend te wurden mei de fjouwer haadpylders fan administraasje:
- Dokumintaasje
- Template
- Optimalisaasje
- Automatisearring
Dit is de basis. As jo jo workflow net bouwe op dizze prinsipes, sil it net effektyf, unproduktyf wêze en oer it algemien net folle oerienkomst hawwe mei echte administraasje. Litte wy elk apart sjen.
Dokumintaasje
Dokumintaasje betsjut net it lêzen fan dokumintaasje (hoewol't jo net sûnder kinne), mar ek it ûnderhâlden.
Hoe dokumintaasje bewarje:
- Hawwe jo in nij probleem tsjinkaam dat jo noch noait earder sjoen hawwe? Skriuw de wichtichste symptomen, metoaden fan diagnoaze en prinsipes fan eliminaasje.
- Ha jo komme mei in nije, elegante oplossing foar in mienskiplik probleem? Skriuw it op, sadat jo it net oer in moanne wer útfine moatte.
- Hawwe se jo holpen in fraach út te finen dy't jo net begrepen? Skriuw de haadpunten en begripen op, tekenje in diagram foar josels.
It haadgedachte: jo moatte jo eigen ûnthâld net folslein fertrouwe by it behearskjen en tapassen fan nije dingen.
Yn hokker formaat jo dit sille dwaan is oan jo: it kin in systeem wêze mei notysjes, in persoanlik blog, in tekstbestân, in fysyk notepad. It wichtichste is dat jo records foldogge oan de folgjende easken:
- Wês net te lang. Markearje de wichtichste ideeën, metoaden en ark. As it begripen fan in probleem fereasket dûke yn 'e meganika op leech nivo fan ûnthâldtawizing yn Linux, skriuw dan it artikel wêrfan jo it leard hawwe net oer - jou in keppeling nei it.
- De ynstjoerings moatte dúdlik wêze foar jo. As de line
race cond.lockuplit jo net fuortendaliks begripe wat jo beskreaun hawwe mei dizze rigel - ferklearje. Goede dokumintaasje nimt gjin healoere om te begripen. - Sykje is in heul goede funksje. As jo blog berjochten skriuwe, add tags; as yn in fysyk notebook, plak dan lytse post-its mei beskriuwingen. D'r hat gjin sin oan dokumintaasje as jo safolle tiid besteegje oan it sykjen nei in antwurd dêryn as jo soene hawwe bestege oan it oplossen fan de fraach fanôf it begjin.
Dit is hoe dokumintaasje der útsjen kin: fan primitive notysjes yn in notepad (foto hjirboppe), oant in folweardige multi-brûker kennisbasis mei tags, sykjen en alle mooglike gemak (ûnder).
Net allinich hoege jo net twa kear nei deselde antwurden te sykjen, mar it dokumintearjen sil in geweldige help wêze by it learen fan nije ûnderwerpen (notysjes!), sil jo spin-sin ferbetterje (de mooglikheid om in kompleks probleem te diagnostearjen mei ien oerflakkich eachopslach), en sil organisaasje tafoegje oan jo aksjes. As de dokumintaasje beskikber is foar jo kollega's, dan kinne se útfine wat en hoe't jo dêr opsteapele hawwe as jo der net binne.
Template
Template is it meitsjen en brûken fan sjabloanen. Om de meast typyske problemen op te lossen, is it wurdich in spesifike aksjesjabloan te meitsjen. In standerdisearre folchoarder fan stappen moat brûkt wurde om de measte problemen te diagnostearjen. As jo wat hawwe reparearre / ynstalleare / optimalisearre, moatte de prestaasjes fan dit iets wurde kontrolearre mei standertisearre checklists.
Sjabloanen is de bêste manier om jo workflow te organisearjen. Troch standertprosedueres te brûken om de meast foarkommende problemen op te lossen, krije jo in protte coole dingen. As jo bygelyks checklists brûke, kinne jo alle funksjes diagnostisearje dy't wichtich binne foar jo wurk en de diagnoaze fan unwichtige funksjonaliteit ferwiderje. En standerdisearre prosedueres sille ûnnedige goaien minimalisearje en de kâns op flater ferminderje.
It earste wichtige punt is dat prosedueres en checklists ek dokumintearre wurde moatte. As jo gewoan fertrouwe op ûnthâld, kinne jo misse wat echt wichtige kontrôle of operaasje en ruine alles. It twadde wichtige punt is dat alle sjabloanpraktiken kinne en moatte wurde wizige as de situaasje it fereasket. D'r binne gjin ideale en absolút universele sjabloanen. As der in probleem, mar in sjabloan kontrôle die bliken it net, dit betsjut net dat der gjin probleem. Foardat jo begjinne te testen wat ûnwierskynlike hypotetyske problemen, is it lykwols altyd wurdich earst in flugge sjabloantest te dwaan.
Optimalisaasje
Optimalisaasje sprekt foar himsels. It wurkproses moat op it mêd fan tiid en arbeidskosten safolle mooglik optimalisearre wurde. D'r binne ûntelbere opsjes: fluchtoetsen leare, ôfkoartings, reguliere útdrukkingen, beskikbere ark. Sjoch foar mear praktyske gebrûk fan dizze ark. As jo in kommando 100 kear deis neame, jou it dan oan in toetseboerd fluchtoets. As jo regelmjittich ferbine moatte mei deselde servers, skriuw dan in alias yn ien wurd dat jo dêr ferbine sil:
Fertroud meitsje mei de ferskate opsjes beskikber foar ark - miskien is d'r in handiger terminalkliïnt, DE, klamboerdbehearder, browser, e-postkliïnt, bestjoeringssysteem. Fyn út hokker ark jo kollega's en freonen brûke - miskien kieze se se foar in reden. Sadree't jo de ark hawwe, learje jo hoe't jo se brûke: learje de kaaien, ôfkoartings, tips en trúkjes.
Meitsje optimaal gebrûk fan standert ark - coreutils, vim, reguliere útdrukkingen, bash. Foar de lêste trije binne d'r in grut oantal prachtige hânboeken en dokumintaasje. Mei har help kinne jo fluch gean fan 'e steat fan "Ik fiel my as in aap dy't noten kraakt mei in laptop" nei "Ik bin in aap dy't in laptop brûkt om mysels in nutenkraker te bestellen."
Automatisearring
Automatisearring sil lestige operaasjes oerdrage fan ús wurge hannen nei de ûnmooglike hannen fan automatisearring. As guon standertproseduere wurdt útfierd yn fiif kommando's fan itselde type, wêrom dan net al dizze kommando's yn ien bestân ynpakke en ien kommando neame dat dit bestân downloade en útfiert?
Automatisearring sels is 80% it skriuwen en optimalisearjen fan jo eigen ark (en nochris 20% besykje se te wurkjen sa't se moatte). It kin gewoan in avansearre one-liner wêze as in enoarm omnipotint ark mei in webynterface en API. It wichtichste kritearium hjir is dat it meitsjen fan in ark net mear tiid en muoite moat nimme as de hoemannichte tiid en muoite dat it ark jo sil besparje. As jo fiif oeren besteegje oan it skriuwen fan in skript dat jo noait wer nedich binne, foar in taak dy't jo in oere as twa soe hawwe nommen om sûnder it skript op te lossen, is dit in heul minne workflowoptimalisaasje. Jo kinne fiif oeren besteegje oan it meitsjen fan in ark allinich as it oantal, it type taken en de tiid it tastean, wat net faak it gefal is.
Automatisearring betsjut net needsaaklikerwize it skriuwen fan folweardige skripts. Bygelyks, om in boskje objekten fan itselde type út in list te meitsjen, is in tûke one-liner genôch, dy't automatysk sil dwaan wat jo mei de hân soene dwaan, wikselje tusken finsters, mei heapen copy-paste.
Eins, as jo it administraasjeproses bouwe op dizze fjouwer pylders, kinne jo jo effisjinsje, produktiviteit en kwalifikaasjes fluch ferheegje. Dizze list moat lykwols oanfolle wurde mei noch ien item, sûnder dat wurkjen yn IT hast ûnmooglik is - selsûnderwiis.
Systeembehearder selsûnderwiis
Om sels in bytsje kompetint te wêzen yn dit gebiet, moatte jo konstant studearje en nije dingen leare. As jo net de minste winsk hawwe om it ûnbekende te ûndersiikjen en it út te finen, sille jo heul gau fêst sitte. Alle soarten nije oplossingen, technologyen en metoaden ferskine konstant yn IT, en as jo se net op syn minst oerflakkich studearje, binne jo op 'e wei nei mislearring. In protte gebieten fan ynformaasjetechnology steane op in heul komplekse en volumineuze basis. Bygelyks, netwurk operaasje. Netwurken en it ynternet binne oeral, jo komme se elke dei tsjin, mar as jo ienris yn 'e technology efter har grave, sille jo in enoarme en heul komplekse dissipline ûntdekke, wêrfan de stúdzje noait in kuier yn it park is.
Ik haw dit item net opnommen yn 'e list, om't it kaai is foar IT yn it algemien, en net allinich foar systeembehear. Fansels kinne jo net direkt alles leare - jo hawwe gewoan net fysyk genôch tiid. Dêrom, as jo josels opliede, moatte jo de nedige abstraksjenivo's ûnthâlde.
Jo hoege jo net fuortendaliks te learen hoe't it ynterne ûnthâldbehear fan elk yndividueel hulpprogramma wurket, en hoe't it ynteraksje mei Linux-ûnthâldbehear, mar it is goed om te witten wat RAM skematysk is en wêrom it nedich is. Jo hoege net te witten hoe't TCP- en UDP-koppen struktureel ferskille, mar it soe in goed idee wêze om de basisferskillen te begripen yn hoe't de protokollen wurkje. Jo hoege net te learen wat sinjaaldemping is yn optyk, mar it soe moai wêze om te witten wêrom't echte ferliezen altyd oer knooppunten oererfd wurde. D'r is neat mis mei te witten hoe't bepaalde eleminten wurkje op in bepaald nivo fan abstraksje en net perfoarst alle nivo's te begripen as d'r hielendal gjin abstraksje is (jo sille gewoan gek wurde).
Lykwols, op jo fjild, tinken op it nivo fan abstraksje "goed, dit is in ding wêrmei jo websiden kinne werjaan" is net heul goed. De folgjende lêzingen sille wijd wurde oan in oersjoch fan 'e haadgebieten dêr't in systeembehearder mei omgean moat by it wurkjen op legere abstraksjenivo's. Ik sil besykje de hoemannichte kennis te beheinen ta in minimum nivo fan abstraksje.
10 geboaden fan systeem administraasje
Dat, wy hawwe de fjouwer haadpylders en stifting leard. Kinne wy begjinne problemen op te lossen? Noch net. Foardat jo dit dogge, is it oan te rieden om josels bekend te meitsjen mei de saneamde "best practices" en regels fan goede manieren. Sûnder harren sille jo wierskynlik mear skea dwaan as goed. Dus, litte wy begjinne:
- Guon fan myn kollega's leauwe dat de alderearste regel is "dogge gjin kwea." Mar ik bin oanstriid om it net iens te wêzen. As jo besykje gjin kwea te dwaan, kinne jo neat dwaan - tefolle aksjes binne potinsjeel destruktyf. Ik tink dat de wichtichste regel is - "meitsje in reservekopy". Sels as jo wat skea dogge, kinne jo altyd werom rôlje en alles sil net sa slim wêze.
Jo moatte altyd reservekopy meitsje as tiid en plak it tastean. Jo moatte reservekopy meitsje fan wat jo sille feroarje en wat jo riskearje te ferliezen troch in mooglik destruktive aksje. It is oan te rieden om te kontrolearjen de reservekopy foar yntegriteit en de oanwêzigens fan alle nedige gegevens. De reservekopy moat net fuortdaliks wiske wurde nei't jo alles kontrolearre hawwe, útsein as jo skiifromte frijmeitsje moatte. As de lokaasje it fereasket, reservekopy it dan nei jo persoanlike server en wiskje it nei in wike.
- De twadde wichtichste regel (dy't ik sels faak brek) is "net ferbergje". As jo in reservekopy makke hawwe, skriuw dan wêr, sadat jo kollega's der net nei hoege te sykjen. As jo wat net foar de hân lizzende of komplekse aksjes hawwe dien, skriuw it dan op: jo sille nei hûs gean, en it probleem kin wurde werhelle of ûntstean foar in oar, en jo oplossing sil fûn wurde mei kaaiwurden. Sels as jo iets dogge dat jo goed witte, kinne jo kollega's net.
- De tredde regel moat net útlein wurde: "Nea dwaan wat de gefolgen wêrfan jo net witte, foarstelle of begripe". Kopiearje gjin kommando's fan it ynternet as jo net witte wat se dogge, skilje man en parse se earst. Brûk gjin klearmakke oplossingen as jo net kinne begripe wat se dogge. Hâld de útfiering fan obfuscated koade ta in absolút minimum. As jo gjin tiid hawwe om it út te finen, dan dogge jo wat ferkeard en moatte jo it folgjende punt lêze.
- "Toets". Nije skripts, ark, ienliners en kommando's moatte wurde hifke yn in kontroleare omjouwing, net op 'e kliïntmasine, as d'r sels minimaal potinsjeel is foar destruktive aksjes. Sels as jo alles opslein hawwe (en jo hawwe), is downtime net it coolste ding. Meitsje in aparte server / firtuele / chroot foar dit en test dêr. Is der wat stikken? Dan kinne jo it starte op "combat".
- "Kontrolearje". Minimalisearje alle operaasjes dy't jo net kontrolearje. Ien kromme foar pakketôfhinklikens kin de helte fan it systeem nei ûnderen slepe, en de -y-flagge ynsteld foar yum remove jout jo de kâns om jo systeemherstelfeardigens fanôf it begjin te oefenjen. As de aksje gjin unkontroleare alternativen hat, is it folgjende punt in klear makke reservekopy.
- "Kontrôle". Kontrolearje de gefolgen fan jo aksjes en oft jo werom moatte rôlje nei in reservekopy. Kontrolearje om te sjen oft it probleem echt is oplost. Kontrolearje oft de flater wurdt reprodusearre en ûnder hokker betingsten. Kontrolearje wat jo kinne brekke mei jo aksjes. It is net nedich om te fertrouwen yn ús wurk, mar nea te kontrolearjen.
- "Kommunisearje". As jo it probleem net kinne oplosse, freegje dan jo kollega's as se dit tsjinkamen. As jo in kontroversjele beslút wolle tapasse, fyn dan de miening fan jo kollega's. Miskien sille se in bettere oplossing biede. As jo net betrouwen yn jo aksjes, besykje se dan mei jo kollega's. Sels as dit jo gebiet fan saakkundigens is, kin in frisse blik op 'e situaasje in protte ferdúdlikje. Skamje jo net foar jo eigen ûnwittendheid. It is better om in domme fraach te stellen, as in gek te sjen en in antwurd te krijen, dan net de fraach te stellen, gjin antwurd te krijen en úteinlik in gek te wêzen.
- "Net ûnferstannich help wegerje". Dit punt is it omkearde fan 'e foarige. As jo in domme fraach wurde frege, ferdúdlikje en ferklearje. Se freegje om it ûnmooglike - ferklearje dat it ûnmooglik is en wêrom, biede alternativen. As jo gjin tiid hawwe (jo hawwe wirklik gjin tiid, net de winsk) - sis dat jo in driuwende fraach hawwe, in protte wurk, mar jo sille it letter oplosse. As kollega's gjin driuwende taken hawwe, biede dan oan om kontakt mei har op te nimmen en de fraach te delegearjen.
- "Feedback jaan". Hat ien fan jo kollega's in nije technyk of in nij skript begon te brûken, en komme jo negative gefolgen fan dit beslút tsjin? Meld it. Miskien kin it probleem oplost wurde yn trije rigels koade of fiif minuten fan it ferfine fan 'e technyk. Hawwe jo in brek yn jo software tsjinkaam? Rapportearje in brek. As it reprodusearber is of net reprodusearre wurde moat, sil it nei alle gedachten wurde reparearre. Stim jo winsken, suggestjes en konstruktive krityk, en bring fragen foar diskusje as se relevant lykje.
- "Freegje om feedback". Wy binne allegear ûnfolslein, krekt as ús besluten, en de bêste manier om de krektens fan jo beslút te testen is it foar diskusje te bringen. As jo wat hawwe optimalisearre foar in klant, freegje har dan om it wurk te kontrolearjen; miskien is de knelpunt yn it systeem net wêr't jo nei sochten. Jo hawwe in helpskript skreaun - lit it oan jo kollega's sjen, miskien fine se in manier om it te ferbetterjen.
As jo dizze praktiken konstant tapasse yn jo wurk, sille de measte problemen ophâlde problemen te wêzen: jo sille net allinich it oantal eigen flaters en fackups oant in minimum ferminderje, mar jo sille ek de kâns hawwe om flaters te korrigearjen (yn 'e foarm fan backups en kollega's dy't jo sille advisearje om backup te meitsjen). Fierder - allinich technyske details, wêryn't, lykas wy witte, de duvel leit.
De wichtichste ark wêrmei jo mear dan 50% fan 'e tiid moatte wurkje binne grep en vim. Wat koe ienfâldiger? Tekstsykjen en tekstbewurking. Sawol grep as vim binne lykwols krêftige multi-ark wêrtroch jo tekst effisjint kinne sykje en bewurkje. As guon Windows notepad kinne jo gewoan skriuwe / wiskje in rigel, dan yn vim kinne jo dwaan hast alles mei tekst. As jo my net leauwe, skilje dan it kommando vimtutor fan 'e terminal en begjin te learen. Wat grep oanbelanget, is de wichtichste sterkte yn reguliere útdrukkingen. Ja, it ark sels lit jo sykbetingsten ynstelle en gegevens útfiere frij fleksibel, mar sûnder RegExp makket dit net folle sin. En jo moatte reguliere útdrukkingen witte! Op syn minst op basisnivo. Om te begjinnen soe ik jo advisearje om dit te sjen , it beslacht de basis fan reguliere útdrukkingen en har gebrûk yn kombinaasje mei grep. Oh ja, as jo se kombinearje mei vim, krije jo de ULTIMATE POWER-mooglikheid om dingen te dwaan mei tekst dy't jo se moatte markearje mei 18+ ikoanen.
Fan 'e oerbleaune 50% komt 40% fan 'e coreutils toolkit. Foar coreutils kinne jo sjen op de list op , en de hânlieding foar de hiele list is op 'e webside . Wat net yn dizze set is behannele is yn 'e nutsbedriuwen . Jo hoege net alle toetsen út 'e holle te learen, mar it is nuttich om op syn minst rûchwei te witten wat de basisynstruminten kinne dwaan. Jo moatte it tsjil net opnij útfine fan krukken. Ik moast op ien of oare manier linebreuken ferfange troch spaasjes yn 'e útfier fan wat nut, en myn sike harsens joech berte oan in konstruksje lykas sed ':a;N;$!ba;s/n/ /g', in kollega kaam op en ried my mei in biezem fan de konsole wei, en loste doe it probleem op troch te skriuwen tr 'n' ' '.
Ik soe jo advisearje om te ûnthâlden wat elk yndividueel ark docht en de kaaien foar de meast brûkte kommando's; foar al it oare is d'r in minske. Fiel jo frij om te skiljen man as jo twifels. En wês wis dat jo de man sels lêze - it befettet wichtige ynformaasje oer wat jo sille fine.
Troch dizze ark te kennen, sille jo in wichtich part fan 'e problemen dy't jo yn 'e praktyk sille tsjinkomme effektyf kinne oplosse. Yn 'e folgjende lêzingen sille wy sjen wannear't dizze ark en de kaders moatte wurde brûkt foar de ûnderlizzende tsjinsten en applikaasjes wêrop se fan tapassing binne.
FirstVDS systeembehearder Kirill Tsvetkov wie by dy.
Boarne: www.habr.com