Para un administrador do sistema novato: como crear orde do caos

Son administrador do sistema FirstVDS, e este é o texto da primeira charla introdutoria do meu curso curto sobre como axudar aos compañeiros novatos. Os especialistas que recentemente comezaron a participar na administración do sistema enfróntanse a varios dos mesmos problemas. Para ofrecer solucións, comprometínme a escribir esta serie de conferencias. Algunhas cousas nel son específicas para aloxar soporte técnico, pero en xeral, poden ser útiles, se non para todos, entón para moitos. Así que adaptei o texto da charla para compartir aquí.

Non importa como se chame a túa posición, o que importa é que de feito estás implicado na administración. Polo tanto, imos comezar co que debe facer un administrador do sistema. A súa tarefa principal é poñer as cousas en orde, manter a orde e prepararse para futuros aumentos en orde. Sen un administrador do sistema, o servidor convértese nunha desorde. Os rexistros non se escriben, ou se escriben neles as cousas incorrectas, os recursos non se distribúen de forma óptima, o disco énchese de todo tipo de lixo e o sistema comeza a morrer lentamente de tanto caos. Con calma! Os administradores do sistema na súa persoa comezan a resolver problemas e eliminar a desorde!

Pilares da Administración de Sistemas

Non obstante, antes de comezar a resolver problemas, paga a pena familiarizarse cos catro piares principais da administración:

1. Documentación
2. Modelado
3. Optimización
4. Automatización

Este é o básico. Se non creas o teu fluxo de traballo sobre estes principios, será ineficaz, improdutivo e, en xeral, se parecerá pouco á administración real. Vexamos cada un por separado.

Documentación

Documentación non significa ler documentación (aínda que non pode prescindir dela), senón tamén mantela.

Como conservar a documentación:

• Encontrácheste cun novo problema que nunca antes viches? Anota os principais síntomas, métodos de diagnóstico e principios de eliminación.
• Chegou cunha solución nova e elegante a un problema común? Anótao para non ter que reinventalo dentro dun mes.
• Axudáronche a resolver unha pregunta que non entendías? Escribe os puntos e conceptos principais, fai un esquema para ti.

A idea principal: non debes confiar completamente na túa propia memoria ao dominar e aplicar cousas novas.

En que formato vai facer isto depende de ti: pode ser un sistema con notas, un blog persoal, un ficheiro de texto, un bloc de notas físico. O principal é que os teus rexistros cumpran os seguintes requisitos:

1. Non sexa demasiado longo. Destacar as ideas, métodos e ferramentas principais. Se comprender un problema require mergullarse na mecánica de baixo nivel da asignación de memoria en Linux, non reescriba o artigo do que o aprendiches: proporciona unha ligazón a el.
2. As entradas deben quedar claras para ti. Se a liña race cond.lockup non lle permite comprender inmediatamente o que describiu con esta liña - explique. Unha boa documentación non leva media hora en comprender.
3. A busca é unha característica moi boa. Se escribes entradas no blog, engade etiquetas; se nun caderno físico, pega pequenos post-it con descricións. De pouco vale a documentación se dedicas tanto tempo a buscar unha resposta nela como o pasarías a resolver a pregunta desde cero.

Así pode ser a documentación: desde notas primitivas nun bloc de notas (imaxe superior), ata unha base de coñecemento multiusuario completa con etiquetas, busca e todas as comodidades posibles (abaixo).

Non só non terás que buscar as mesmas respostas dúas veces, senón que a documentación será de gran axuda para aprender novos temas (notas!), mellorará o teu sentido de araña (a capacidade de diagnosticar un problema complexo cunha ollada superficial). e engadirá organización ás túas accións. Se a documentación está dispoñible para os teus compañeiros, permitiralles descubrir que e como acumulaches alí cando non esteas.

Modelado

Modelado é a creación e uso de modelos. Para resolver os problemas máis típicos, paga a pena crear un modelo de acción específico. Debe utilizarse unha secuencia estandarizada de pasos para diagnosticar a maioría dos problemas. Cando teña reparado/instalado/optimizado algo, o rendemento deste algo debería comprobarse mediante listas de verificación estandarizadas.

A creación de modelos é a mellor forma de organizar o teu fluxo de traballo. Usando procedementos estándar para resolver os problemas máis comúns, obtén moitas cousas interesantes. Por exemplo, usar listas de verificación permitirache diagnosticar todas as funcións que son importantes para o teu traballo e descartar o diagnóstico de funcionalidades sen importancia. E os procedementos estandarizados minimizarán os lanzamentos innecesarios e reducirán a probabilidade de erro.

O primeiro punto importante é que tamén se deben documentar os procedementos e as listas de verificación. Se só confías na memoria, podes perderte algunha comprobación ou operación moi importante e arruinalo todo. O segundo punto importante é que todas as prácticas de modelos poden e deben modificarse se a situación o require. Non hai modelos ideais e absolutamente universais. Se hai un problema, pero unha comprobación do modelo non o revelou, isto non significa que non haxa ningún problema. Non obstante, antes de comezar a probar algúns problemas hipotéticos improbables, sempre paga a pena facer primeiro unha proba rápida de modelos.

Optimización

Optimización fala por si só. O proceso de traballo debe optimizarse na medida do posible en termos de tempo e custos laborais. Hai moitas opcións: aprender atallos de teclado, abreviaturas, expresións regulares, ferramentas dispoñibles. Busca usos máis prácticos destas ferramentas. Se chamas a un comando 100 veces ao día, asígnao a un atallo de teclado. Se precisa conectarse regularmente aos mesmos servidores, escriba un alias nunha palabra que o conectará alí:

Familiarícese coas diferentes opcións dispoñibles para as ferramentas: quizais haxa un cliente de terminal máis cómodo, DE, xestor de portapapeis, navegador, cliente de correo electrónico, sistema operativo. Descubra cales son as ferramentas que usan os seus compañeiros e amigos; quizais as escollan por algún motivo. Unha vez que teñas as ferramentas, aprende a usalas: aprende as claves, as abreviaturas, os consellos e trucos.

Fai un uso óptimo das ferramentas estándar: coreutils, vim, expresións regulares, bash. Para os tres últimos hai un gran número de manuais e documentación marabillosos. Coa súa axuda, podes pasar rapidamente do estado de "Sinto como un mono que rompe noces cun portátil" a "Son un mono que usa un portátil para pedirme un cascanueces".

Automatización

Automatización transferirá operacións difíciles das nosas mans cansas ás mans incansables da automatización. Se algún procedemento estándar se realiza en cinco comandos do mesmo tipo, entón por que non envolver todos estes comandos nun ficheiro e chamar a un comando que descarga e executa este ficheiro?

A automatización en si é un 80% escribindo e optimizando as túas propias ferramentas (e outro 20% intentando que funcionen como deberían). Podería ser só unha liña avanzada ou unha enorme ferramenta omnipotente cunha interface web e API. O criterio principal aquí é que crear unha ferramenta non debe levar máis tempo e esforzo que a cantidade de tempo e esforzo que che aforrará a ferramenta. Se pasas cinco horas escribindo un script que nunca máis necesitarás, para unha tarefa que che levaría unha ou dúas horas resolver sen o script, esta é unha optimización do fluxo de traballo moi pobre. Podes dedicar cinco horas a crear unha ferramenta só se o número, o tipo de tarefas e o tempo o permiten, o que non adoita ser o caso.

A automatización non significa necesariamente escribir scripts completos. Por exemplo, para crear unha morea de obxectos do mesmo tipo a partir dunha lista, todo o que necesitas é un intelixente one-liner que fará automaticamente o que farías a man, cambiando entre as fiestras, con moreas de copiar e pegar.

En realidade, se constrúe o proceso de administración sobre estes catro piares, pode aumentar rapidamente a súa eficiencia, produtividade e cualificación. Non obstante, esta lista debe ser complementada cun elemento máis, sen o cal é case imposible traballar en TI: a autoeducación.

Autoformación de administrador de sistemas

Para ser aínda un pouco competente nesta área, cómpre estudar e aprender constantemente cousas novas. Se non tes o máis mínimo desexo de enfrontarte ao descoñecido e descifralo, quedarás atrapado moi rapidamente. Todo tipo de novas solucións, tecnoloxías e métodos aparecen constantemente na informática, e se non as estudas polo menos superficialmente, estás no camiño do fracaso. Moitas áreas da tecnoloxía da información están sobre unha base moi complexa e voluminosa. Por exemplo, o funcionamento da rede. As redes e Internet están por todas partes, atópase con elas todos os días, pero unha vez que profundices na tecnoloxía que hai detrás delas, descubrirás unha disciplina enorme e moi complexa, cuxo estudo nunca é un paseo polo parque.

Non incluín este elemento na lista porque é fundamental para a TI en xeral, e non só para a administración do sistema. Por suposto, non poderás aprender absolutamente todo de inmediato; simplemente non tes tempo suficiente fisicamente. Polo tanto, ao educarse, debes lembrar os niveis de abstracción necesarios.

Non tes que aprender de inmediato como funciona a xestión da memoria interna de cada utilidade individual e como interactúa coa xestión da memoria de Linux, pero é bo saber que RAM é esquemáticamente e por que se necesita. Non precisa saber como son estruturalmente diferentes as cabeceiras TCP e UDP, pero sería unha boa idea comprender as diferenzas básicas no funcionamento dos protocolos. Non necesitas saber que é a atenuación do sinal na óptica, pero sería bo saber por que as perdas reais sempre se herdan entre os nodos. Non hai nada de malo en saber como funcionan certos elementos nun certo nivel de abstracción e non necesariamente comprender absolutamente todos os niveis cando non hai abstracción en absoluto (simplemente te volverás tolo).

Non obstante, no teu campo, pensar a nivel de abstracción "ben, isto é algo que che permite mostrar sitios web" non é moi bo. As seguintes conferencias dedicaranse a unha visión xeral das principais áreas coas que un administrador de sistemas debe tratar cando traballa en niveis máis baixos de abstracción. Tentarei limitar a cantidade de coñecementos revisados ​​a un nivel mínimo de abstracción.

10 Mandamentos da Administración de Sistemas

Entón, aprendemos os catro alicerces e fundamentos principais. Podemos comezar a resolver problemas? Aínda non. Antes de facelo, convén familiarizarse coas chamadas "boas prácticas" e as regras de boa educación. Sen eles, é probable que fagas máis mal que ben. Entón, imos comezar:

1. Algúns dos meus compañeiros cren que a primeira regra é "non facer dano". Pero estou inclinado a discrepar. Cando intentas non facer dano, non podes facer nada - demasiadas accións son potencialmente destrutivas. Creo que a regra máis importante é - "facer unha copia de seguridade". Aínda que fagas algún dano, sempre podes retroceder e todo non será tan malo.

   Sempre debes facer unha copia de seguridade cando o tempo e o lugar o permitan. Debe facer unha copia de seguridade do que vai cambiar e do que corre o risco de perder debido a unha acción potencialmente destrutiva. É recomendable comprobar a integridade da copia de seguridade e a presenza de todos os datos necesarios. A copia de seguridade non debe eliminarse inmediatamente despois de comprobar todo, a non ser que necesite liberar espazo no disco. Se a localización o require, fai unha copia de seguranza no teu servidor persoal e elimínao ao cabo dunha semana.

2. A segunda regra máis importante (que eu mesmo incumpo a miúdo) é "non te escondas". Se fixeches unha copia de seguridade, escribe onde, para que os teus compañeiros non teñan que buscala. Se fixeches algunhas accións non obvias ou complexas, anótao: irás a casa e o problema pode repetirse ou xurdir a outra persoa, e a túa solución atoparase mediante palabras clave. Aínda que fagas algo que sabes ben, os teus compañeiros poden non.
3. Non é necesario explicar a terceira regra: "Nunca fagas algo cuxas consecuencias non sabes, imaxinas ou entendes". Non copies comandos de Internet se non sabes o que fan, chama a man e analízaos primeiro. Non use solucións preparadas se non pode entender o que fan. Mantén a execución de código ofuscado ao mínimo. Se non tes tempo para descubrilo, estás facendo algo mal e deberías ler o seguinte punto.
4. "Proba". Os novos scripts, ferramentas, liñas únicas e comandos deberían probarse nun ambiente controlado, non na máquina cliente, se hai un potencial mínimo de accións destrutivas. Aínda que fixeches unha copia de seguranza de todo (e o fixeches), o tempo de inactividade non é o máis xenial. Crea un servidor/virtual/chroot separado para isto e proba alí. Algo está roto? Entón podes lanzalo en "combate".

   
   

5. "Control". Minimiza todas as operacións que non controlas. Unha curva de dependencia de paquetes pode arrastrar a metade do sistema cara abaixo, e a bandeira -y definida para eliminar yum dáche a oportunidade de practicar as túas habilidades de recuperación do sistema desde cero. Se a acción non ten alternativas incontroladas, o seguinte punto é unha copia de seguridade preparada.
6. "Comprobar". Comproba as consecuencias das túas accións e se necesitas volver a unha copia de seguranza. Comproba se o problema foi realmente resolto. Comproba se o erro se reproduce e en que condicións. Comproba o que podes romper coas túas accións. Non é necesario confiar no noso traballo, pero nunca comprobar.
7. "Comunicar". Se non podes resolver o problema, pregúntalles aos teus compañeiros se se atoparon con isto. Se queres aplicar unha decisión controvertida, infórmate da opinión dos teus compañeiros. Quizais ofrezan unha mellor solución. Se non confías nas túas accións, coméntaas cos teus compañeiros. Aínda que esta sexa a túa área de especialización, unha nova mirada á situación pode aclarar moito. Non teñas vergoña da túa propia ignorancia. É mellor facer unha pregunta estúpida, parecer un parvo e obter unha resposta, que non facer a pregunta, non obter unha resposta e acabar sendo un parvo.
8. "Non rexeites a axuda sen razón". Este punto é o inverso do anterior. Se che fai unha pregunta estúpida, aclara e explica. Piden o imposible, explican que é imposible e por que ofrecen alternativas. Se non tes tempo (realmente non tes o tempo, non o desexo) - di que tes unha pregunta urxente, moito traballo, pero resolverao máis tarde. Se os compañeiros non teñen tarefas urxentes, ofrécese a contactar con eles e delegar a pregunta.
9. "Dar comentarios". Algún dos teus colegas comezou a utilizar unha nova técnica ou un novo guión e estás atopando con consecuencias negativas desta decisión? Informalo. Quizais o problema se poida resolver en tres liñas de código ou cinco minutos de refinar a técnica. Encontrou un erro no seu software? Informar dun erro. Se é reproducible ou non é necesario reproducilo, o máis probable é que se solucione. Expresa os teus desexos, suxestións e críticas construtivas e fai preguntas para debater se parecen relevantes.
10. "Pedir comentarios". Todos somos imperfectos, igual que as nosas decisións, e a mellor forma de probar a corrección da túa decisión é levala a debate. Se optimizou algo para un cliente, pídalle que vixien o traballo; quizais o pescozo de botella no sistema non estea onde estaba a buscar. Escribiches un guión de axuda: móstrao aos teus colegas, quizais atopen unha forma de melloralo.

Se aplicas constantemente estas prácticas no teu traballo, a maioría dos problemas deixarán de ser problemas: non só reducirás ao mínimo o número dos teus propios erros e erros, senón que tamén terás a oportunidade de corrixilos (no forma de copias de seguridade e colegas que che aconsellarán facer unha copia de seguridade). Ademais - só os detalles técnicos, nos que, como sabemos, o demo mente.

As principais ferramentas coas que terás que traballar máis do 50% do tempo son grep e vim. Que podería ser máis sinxelo? Busca e edición de textos. Non obstante, tanto grep como vim son poderosas ferramentas múltiples que che permiten buscar e editar texto de forma eficiente. Se algún bloc de notas de Windows permíteche simplemente escribir/eliminar unha liña, entón en vim podes facer case calquera cousa con texto. Se non me cres, chama ao comando vimtutor desde o terminal e comeza a aprender. En canto ao grep, a súa principal forza está nas expresións regulares. Si, a propia ferramenta permítelle establecer condicións de busca e obter datos de forma bastante flexible, pero sen RegExp isto non ten moito sentido. E precisas saber expresións regulares! Polo menos a nivel básico. Para comezar, aconsellaríache que o fixeras video, abrangue os conceptos básicos das expresións regulares e o seu uso xunto con grep. Ah, si, cando os combinas con vim, obténs a capacidade ULTIMATE POWER para facer cousas con texto que tes que etiquetalos con máis de 18 iconas.

Do 50% restante, o 40% provén do conxunto de ferramentas coreutils. Para coreutils podes mirar a lista en Wikipedia, e o manual para toda a lista está no sitio web GNU. O que non está cuberto neste conxunto está nas utilidades POSIX. Non tes que aprender todas as claves de memoria, pero é útil saber polo menos o que poden facer as ferramentas básicas. Non tes que reinventar a roda con muletas. Dalgunha maneira necesitaba substituír os saltos de liña por espazos na saída dalgunha utilidade, e o meu cerebro enfermo deu a luz a unha construción como sed ':a;N;$!ba;s/n/ /g', achegouse un compañeiro e afastoume da consola cunha vasoira, e despois resolveu o problema escribindo tr 'n' ' '.

Recoméndoche lembrar o que fai cada ferramenta individual e as claves dos comandos de uso máis frecuente; para todo o demais hai home. Non dubide en chamar home se tes algunha dúbida. E asegúrate de ler o propio home: contén información importante sobre o que atoparás.

Coñecendo estas ferramentas, poderás resolver de forma eficaz unha parte importante dos problemas que atoparás na práctica. Nas seguintes conferencias, analizaremos cando usar estas ferramentas e os marcos para os servizos e aplicacións subxacentes aos que se aplican.

O administrador do sistema FirstVDS, Kirill Tsvetkov, estivo contigo.

Fonte: www.habr.com