Sóc administrador del sistema FirstVDS, i aquest és el text de la primera conferència introductòria del meu curs breu sobre com ajudar els col·legues novells. Els especialistes que recentment han començat a dedicar-se a l'administració del sistema s'enfronten a diversos problemes. Per oferir solucions, em vaig comprometre a escriure aquest cicle de conferències. Algunes coses són específiques per allotjar suport tècnic, però en general, poden ser útils, si no per a tothom, per a molts. Així que he adaptat el text de la conferència per compartir-lo aquí.
No importa com es digui la teva posició: el que importa és que de fet participis en l'administració. Per tant, comencem pel que hauria de fer un administrador del sistema. La seva tasca principal és posar ordre, mantenir l'ordre i preparar-se per a futurs augments en ordre. Sense un administrador del sistema, el servidor es converteix en un desastre. Els registres no s'escriuen, o s'escriuen coses incorrectes, els recursos no es distribueixen de manera òptima, el disc s'omple de tot tipus d'escombraries i el sistema comença a morir lentament per tant de caos. Amb calma! Els administradors del sistema en la teva persona comencen a resoldre problemes i eliminar l'embolic!
Pilars de l'administració de sistemes
Tanmateix, abans de començar a resoldre problemes, val la pena familiaritzar-se amb els quatre pilars principals de l'administració:
- Documentació
- Plantilla
- Optimització
- Automatització
Això és el bàsic. Si no construïu el vostre flux de treball sobre aquests principis, serà ineficaç, improductiu i, en general, s'assemblarà poc a l'administració real. Vegem-ne cadascun per separat.
Registres
Registres no vol dir llegir documentació (tot i que no hi ha manera d'evitar-la), sinó també mantenir-la.
Com conservar la documentació:
- T'has trobat amb un problema nou que mai has vist abans? Anoteu els principals símptomes, mètodes de diagnòstic i principis d'eliminació.
- Heu trobat una solució nova i elegant a un problema comú? Anoteu-lo per no haver de reinventar-lo d'aquí a un mes.
- T'han ajudat a esbrinar una pregunta que no entenies? Escriu els punts i conceptes principals, dibuixa un diagrama per tu mateix.
La idea principal: no hauries de confiar completament en la teva pròpia memòria quan domines i apliques coses noves.
En quin format ho faràs depèn de tu: podria ser un sistema amb notes, un bloc personal, un fitxer de text, un bloc de notes físic. El més important és que els vostres registres compleixin els requisits següents:
- No siguis massa llarg. Ressaltar les idees, mètodes i eines principals. Si entendre un problema requereix submergir-se en la mecànica de baix nivell de l'assignació de memòria a Linux, no torneu a escriure l'article del qual l'heu après; proporcioneu-hi un enllaç.
- Les entrades haurien de ser clares per a tu. Si la línia
race cond.lockupno us permet entendre immediatament el que heu descrit amb aquesta línia: expliqueu. Una bona documentació no triga ni mitja hora a entendre's. - La cerca és una característica molt bona. Si feu un blog, afegiu etiquetes; si en un quadern físic, enganxeu petits post-it amb descripcions. No serveix de res la documentació si dediques tant de temps a buscar-hi una resposta com t'hauries dedicat a resoldre la pregunta des de zero.
Així és com pot semblar la documentació: des de notes primitives en un bloc de notes (imatge de dalt), fins a una base de coneixement multiusuari completa amb etiquetes, cerca i totes les comoditats possibles (a sota).
No només no hauràs de buscar les mateixes respostes dues vegades, sinó que documentar-te serà de gran ajuda per aprendre nous temes (notes!), millorarà el teu sentit d'aranya (la capacitat de diagnosticar un problema complex amb una mirada superficial). i afegirà organització a les vostres accions. Si la documentació està a disposició dels vostres companys, els permetrà esbrinar què i com hi vau amuntegar quan no hi sou.
Plantilla
Plantilla és la creació i ús de plantilles. Per resoldre els problemes més habituals, val la pena crear una plantilla d'acció específica. S'ha d'utilitzar una seqüència estandarditzada de passos per diagnosticar la majoria dels problemes. Quan hàgiu reparat/instal·lat/optimitzat alguna cosa, s'ha de comprovar el rendiment d'aquesta cosa mitjançant llistes de verificació estandarditzades.
La plantilla és la millor manera d'organitzar el vostre flux de treball. Utilitzant procediments estàndard per resoldre els problemes més comuns, obtindreu moltes coses interessants. Per exemple, l'ús de llistes de verificació us permetrà diagnosticar totes les funcions que són importants per al vostre treball i descartar el diagnòstic de funcionalitats sense importància. I els procediments estandarditzats minimitzaran els llançaments innecessaris i reduiran la probabilitat d'error.
El primer punt important és que els procediments i les llistes de verificació també s'han de documentar. Si només confieu en la memòria, us podeu perdre una comprovació o operació molt important i arruïnar-ho tot. El segon punt important és que totes les pràctiques de plantilla poden i s'han de modificar si la situació ho requereix. No hi ha plantilles ideals i absolutament universals. Si hi ha un problema, però una comprovació de la plantilla no l'ha revelat, això no vol dir que no hi hagi cap problema. Tanmateix, abans de començar a provar alguns problemes hipotètics poc probables, sempre val la pena fer primer una prova ràpida de plantilla.
Optimització
Optimització parla per si mateix. Cal optimitzar el procés de treball tant com sigui possible en termes de temps i costos laborals. Hi ha innombrables opcions: aprendre dreceres de teclat, abreviatures, expressions regulars, eines disponibles. Busqueu usos més pràctics d'aquestes eines. Si truqueu una ordre 100 vegades al dia, assigneu-la a una drecera de teclat. Si necessiteu connectar-vos regularment als mateixos servidors, escriviu un àlies en una paraula que us connecti allà:
Familiaritzeu-vos amb les diferents opcions disponibles per a les eines; potser hi ha un client de terminal més convenient, DE, gestor de porta-retalls, navegador, client de correu electrònic, sistema operatiu. Descobriu quines eines fan servir els vostres companys i amics; potser les trien per alguna raó. Un cop tingueu les eines, apreneu a utilitzar-les: apreneu les tecles, les abreviatures, els consells i els trucs.
Feu un ús òptim de les eines estàndard: coreutils, vim, expressions regulars, bash. Per als tres últims, hi ha un gran nombre de manuals i documentació meravellosos. Amb la seva ajuda, podeu passar ràpidament de l'estat de "Em sento com un mico que trenca fruits secs amb un ordinador portàtil" a "Sóc un mico que fa servir un ordinador portàtil per demanar-me un trencaclosques".
Automatització
Automatització transferirà operacions difícils de les nostres mans cansades a les mans incansables de l'automatització. Si es realitza algun procediment estàndard en cinc ordres del mateix tipus, per què no embolicar totes aquestes ordres en un sol fitxer i cridar una ordre que descarregui i executi aquest fitxer?
L'automatització en si és un 80% escriure i optimitzar les vostres pròpies eines (i un altre 20% intentant que funcionin com haurien de ser). Podria ser només una línia avançada o una gran eina omnipotent amb una interfície web i API. El criteri principal aquí és que la creació d'una eina no hauria de prendre més temps i esforç que la quantitat de temps i esforç que l'eina us estalviarà. Si passeu cinc hores escrivint un script que mai més necessitareu, per a una tasca que us hauria costat una o dues hores a resoldre sense l'script, aquesta és una optimització del flux de treball molt pobra. Podeu dedicar cinc hores a crear una eina només si el nombre, el tipus de tasques i el temps ho permeten, cosa que no sol ser el cas.
L'automatització no vol dir necessàriament escriure scripts complets. Per exemple, per crear un munt d'objectes del mateix tipus a partir d'una llista, tot el que necessiteu és una línia intel·ligent que faci automàticament el que farieu a mà, canviant entre finestres, amb un munt de còpia i enganxa.
De fet, si construeixes el procés d'administració sobre aquests quatre pilars, pots augmentar ràpidament la teva eficiència, productivitat i qualificació. Tanmateix, aquesta llista s'ha de complementar amb un element més, sense el qual treballar en TI és gairebé impossible: l'autoeducació.
Autoeducació d'administrador de sistemes
Per ser fins i tot una mica competent en aquesta àrea, cal estudiar i aprendre coses noves constantment. Si no tens el més mínim desig d'enfrontar-te al desconegut i descobrir-ho, t'encallaràs molt ràpidament. Tot tipus de noves solucions, tecnologies i mètodes apareixen constantment a les TI, i si no les estudies almenys superficialment, estàs en el camí del fracàs. Moltes àrees de la tecnologia de la informació es troben sobre una base molt complexa i voluminosa. Per exemple, el funcionament de la xarxa. Les xarxes i Internet són a tot arreu, les trobes cada dia, però un cop aprofundeixes en la tecnologia que hi ha darrere, descobriràs una disciplina enorme i molt complexa, l'estudi de la qual mai és un passeig pel parc.
No he inclòs aquest element a la llista perquè és clau per a TI en general, i no només per a l'administració del sistema. Naturalment, no podreu aprendre absolutament tot de seguida; simplement no teniu prou temps físicament. Per tant, a l'hora d'educar-se, hauríeu de recordar els nivells d'abstracció necessaris.
No cal que aprengui immediatament com funciona la gestió de la memòria interna de cada utilitat individual i com interactua amb la gestió de la memòria de Linux, però és bo saber quina és la memòria RAM esquemàticament i per què es necessita. No cal saber com les capçaleres TCP i UDP són estructuralment diferents, però seria una bona idea entendre les diferències bàsiques en el funcionament dels protocols. No cal saber què és l'atenuació del senyal a l'òptica, però seria bo saber per què les pèrdues reals sempre s'hereten entre els nodes. No hi ha res dolent en saber com funcionen determinats elements a un cert nivell d'abstracció i no necessàriament entendre absolutament tots els nivells quan no hi ha cap abstracció (se'n tornarà boig).
Tanmateix, en el vostre camp, pensar a nivell d'abstracció "bé, això és una cosa que us permet mostrar llocs web" no és gaire bo. Les conferències següents es dedicaran a una visió general de les àrees principals que ha de tractar un administrador de sistemes quan treballa a nivells d'abstracció inferiors. Intentaré limitar la quantitat de coneixements revisats a un nivell mínim d'abstracció.
10 manaments de l'administració del sistema
Així doncs, hem après els quatre pilars i fonaments principals. Podem començar a resoldre problemes? Encara no. Abans de fer-ho, és recomanable familiaritzar-se amb les anomenades “pràctiques bones” i normes de bones maneres. Sense ells, és probable que facis més mal que bé. Així doncs, comencem:
- Alguns dels meus companys creuen que la primera regla és "no fer mal". Però estic inclinat a no estar d'acord. Quan intenteu no fer mal, no podeu fer res: massa accions són potencialment destructives. Crec que la regla més important és... "Fer una còpia de seguretat". Fins i tot si feu algun dany, sempre podeu retrocedir i tot no anirà tan malament.
Sempre hauríeu de fer una còpia de seguretat quan el temps i el lloc ho permetin. Heu de fer una còpia de seguretat del que canviareu i del que correu el risc de perdre a causa d'una acció potencialment destructiva. És recomanable comprovar la integritat de la còpia de seguretat i la presència de totes les dades necessàries. La còpia de seguretat no s'ha de suprimir immediatament després de comprovar-ho tot, tret que hàgiu d'alliberar espai al disc. Si la ubicació ho requereix, feu-ne una còpia de seguretat al vostre servidor personal i suprimiu-la al cap d'una setmana.
- La segona regla més important (que jo mateix incompleixo sovint) és "no amagar". Si has fet una còpia de seguretat, escriu on, perquè els teus companys no l'hagin de buscar. Si heu fet algunes accions no òbvies o complexes, anoteu-les: tornareu a casa i el problema es pot repetir o sorgir per a algú altre, i la vostra solució es trobarà amb paraules clau. Encara que facis alguna cosa que saps bé, els teus companys potser no.
- No cal explicar la tercera regla: "No facis mai alguna cosa les conseqüències de les quals no sàpigues, imagines o entengues". No copieu ordres d'Internet si no sabeu què fan, truqueu a l'home i analitzeu-les primer. No utilitzeu solucions ja fetes si no podeu entendre què fan. Mantingueu l'execució de codi ofuscat al mínim absolut. Si no tens temps d'esbrinar-ho, aleshores estàs fent alguna cosa malament i hauries de llegir el punt següent.
- "Prova". Els nous scripts, eines, línies i ordres s'han de provar en un entorn controlat, no a la màquina client, si fins i tot hi ha un potencial mínim d'accions destructives. Fins i tot si heu fet una còpia de seguretat de tot (i ho heu fet), el temps d'inactivitat no és el millor. Creeu un servidor/virtual/chroot separat per a això i proveu-hi. S'ha trencat alguna cosa? A continuació, podeu llançar-lo a "combat".
- "Control". Minimitzeu totes les operacions que no controleu. Una corba de dependència del paquet pot arrossegar la meitat del sistema cap avall, i la marca -y establerta per a yum remove us ofereix l'oportunitat de practicar les vostres habilitats de recuperació del sistema des de zero. Si l'acció no té alternatives incontrolades, el punt següent és una còpia de seguretat ja feta.
- "Comprovar". Comproveu les conseqüències de les vostres accions i si heu de tornar a una còpia de seguretat. Comproveu si el problema s'ha resolt realment. Comproveu si l'error es reprodueix i en quines condicions. Comproveu què podeu trencar amb les vostres accions. És innecessari confiar en la nostra feina, però mai comprovar-ho.
- "Comunicar-se". Si no podeu resoldre el problema, pregunteu als vostres companys si s'han trobat amb això. Si vols aplicar una decisió controvertida, consulta l'opinió dels teus companys. Potser oferiran una millor solució. Si no confieu en les vostres accions, discutiu-les amb els vostres companys. Fins i tot si aquesta és la vostra àrea d'experiència, una mirada nova a la situació pot aclarir molt. No t'avergonyis de la teva pròpia ignorància. És millor fer una pregunta estúpida, semblar un ximple i obtenir una resposta, que no fer la pregunta, no obtenir una resposta i acabar sent un ximple.
- "No neguis ajuda sense raó". Aquest punt és el contrari de l'anterior. Si et fan una pregunta estúpida, aclareix i explica. Demanen l'impossible, expliquen que és impossible i per què, ofereixen alternatives. Si no tens temps (realment no tens temps, no ganes) - digues que tens una pregunta urgent, molta feina, però ho solucionaràs més tard. Si els companys no tenen tasques urgents, ofereix-te a contactar amb ells i delega la pregunta.
- "Donar comentaris". Algun dels teus companys ha començat a utilitzar una tècnica o un guió nou i estàs trobant conseqüències negatives d'aquesta decisió? Denuncia-ho. Potser el problema es pot resoldre en tres línies de codi o cinc minuts de perfeccionament de la tècnica. Us heu trobat amb un error al vostre programari? Informar d'un error. Si és reproduïble o no cal reproduir-lo, el més probable és que es solucioni. Expresseu els vostres desitjos, suggeriments i crítiques constructives, i plantegeu preguntes per discutir si us semblen rellevants.
- "Demana comentaris". Tots som imperfectes, igual que les nostres decisions, i la millor manera de provar la correcció de la vostra decisió és portar-la a discussió. Si heu optimitzat alguna cosa per a un client, demaneu-li que supervisin el treball, potser el coll d'ampolla del sistema no és on estaves buscant. Heu escrit un guió d'ajuda; mostreu-lo als vostres companys, potser trobaran una manera de millorar-lo.
Si apliqueu aquestes pràctiques constantment a la vostra feina, la majoria dels problemes deixaran de ser problemes: no només reduireu el nombre dels vostres propis errors i faltes al mínim, sinó que també tindreu l'oportunitat de corregir-los (en el forma de còpies de seguretat i companys que us aconsellaran fer còpies de seguretat). A més, només detalls tècnics, en els quals, com sabem, rau el diable.
Les principals eines amb les quals hauràs de treballar més del 50% del temps són grep i vim. Què podria ser més senzill? Cerca de text i edició de text. Tanmateix, tant grep com vim són potents eines múltiples que us permeten cercar i editar text de manera eficient. Si algun bloc de notes de Windows us permet simplement escriure/suprimir una línia, a vim podeu fer gairebé qualsevol cosa amb text. Si no em creus, truca a l'ordre vimtutor des del terminal i comença a aprendre. Pel que fa al grep, la seva principal força està en les expressions regulars. Sí, l'eina en si us permet establir condicions de cerca i dades de sortida amb força flexibilitat, però sense RegExp això no té gaire sentit. I cal saber expressions regulars! Almenys a nivell bàsic. Per començar, us aconsello que mireu això , cobreix els conceptes bàsics de les expressions regulars i el seu ús juntament amb grep. Ah, sí, quan els combineu amb vim, obteniu l'habilitat de POTÈNCIA MÀXIMA per fer coses amb text que els heu d'etiquetar amb més de 18 icones.
Del 50% restant, el 40% prové del conjunt d'eines coreutils. Per a coreutils podeu consultar la llista a , i el manual de tota la llista es troba al lloc web . El que no està cobert en aquest conjunt està en les utilitats . No cal que aprenguis totes les claus de memòria, però és útil saber com a mínim què poden fer les eines bàsiques. No cal reinventar la roda amb crosses. D'alguna manera necessitava substituir els salts de línia per espais a la sortida d'alguna utilitat, i el meu cervell malalt va donar a llum una construcció com sed ':a;N;$!ba;s/n/ /g', va venir un company i em va allunyar de la consola amb una escombra, i després va resoldre el problema escrivint tr 'n' ' '.
Us aconsello que recordeu què fa cada eina individual i les claus de les ordres més utilitzades per a tota la resta d'home. No dubteu a trucar a l'home si teniu cap dubte. I assegureu-vos de llegir el propi home: conté informació important sobre el que trobareu.
Coneixent aquestes eines, podràs resoldre eficaçment una part important dels problemes que et trobaràs a la pràctica. A les conferències següents, veurem quan utilitzar aquestes eines i els marcs dels serveis i aplicacions subjacents als quals s'apliquen.
L'administrador del sistema FirstVDS, Kirill Tsvetkov, estava amb tu.
Font: www.habr.com