{"id":34841,"date":"2019-10-31T22:00:43","date_gmt":"2019-10-31T19:00:43","guid":{"rendered":"https:\/\/prohoster.info\/blog\/avtomatizatsiya-zameny-diskov-s-pomoshhyu-ansible\/"},"modified":"2019-10-31T22:00:43","modified_gmt":"2019-10-31T19:00:43","slug":"avtomatizatsiya-zameny-diskov-s-pomoshhyu-ansible","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/avtomatizatsiya-zameny-diskov-s-pomoshhyu-ansible","title":{"rendered":"Automazione della sostituzione dei dischi tramite Ansible","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Automazione
\n
\nCiao a tutti. Lavoro come amministratore di sistema senior in OK e mi occupo del funzionamento stabile del portale. Voglio raccontarvi come abbiamo organizzato il processo di sostituzione automatica dei dischi e come abbiamo escluso l'amministratore da questo processo, sostituendolo con un bot.<\/p>\n

Questo articolo \u00e8 una sorta di traslitterazione dell'esibizione<\/a><\/noindex> a HighLoad+ 2018
\n<\/a><\/noindex><\/p>\n

Costruzione del processo di sostituzione dei dischi<\/h2>\n

<\/p>\n

Iniziamo con qualche numero<\/h3>\n

\nOK \u00e8 un gigantesco servizio utilizzato da milioni di persone. \u00c8 supportato da circa 7.000 server situati in 4 diversi data center. I server ospitano oltre 70.000 dischi. Se impilati, formerebbero una torre alta oltre 1 km. <\/p>\n

I dischi rigidi sono il componente del server che si guasta pi\u00f9 spesso. Con questi volumi, dobbiamo sostituire circa 30 dischi a settimana, e questa procedura \u00e8 diventata una routine piuttosto spiacevole.<\/p>\n

\"Automazione
\n<\/p>\n

Incidenti<\/h3>\n

\nNella nostra azienda \u00e8 stato implementato un completo sistema di gestione degli incidenti. Ogni incidente viene registrato in Jira e poi risolto e analizzato. Se l'incidente ha avuto un impatto sugli utenti, ci riuniamo per riflettere su come reagire pi\u00f9 rapidamente in tali situazioni, ridurre l'impatto e, naturalmente, prevenire ripetizioni.<\/p>\n

I drive non fanno eccezione. Il loro stato \u00e8 monitorato da Zabbix. Controlliamo i messaggi nel Syslog per errori di scrittura\/lettura, analizziamo lo stato dei RAID HW\/SW e monitoriamo il valore SMART; per gli SSD calcoliamo l'usura. <\/p>\n

Come cambiavano i dischi in passato<\/h3>\n

\nQuando in Zabbix si attiva un trigger, viene creato un incidente in Jira e automaticamente assegnato agli ingegneri pertinenti nei data center. Facciamo cos\u00ec con tutti gli incidenti HW, cio\u00e8 quelli che richiedono qualche lavoro fisico con l'attrezzatura nel data center.
\nL'ingegnere del data center \u00e8 la persona che si occupa delle questioni relative all'hardware, responsabile dell'installazione, della manutenzione e della rimozione dei server. Appena riceve un ticket, l'ingegnere inizia a lavorare. Nelle unit\u00e0 di disco, sostituisce i dischi da solo. Se non ha accesso al dispositivo necessario, si rivolge agli amministratori di sistema di turno per ricevere aiuto. In primo luogo, \u00e8 necessario rimuovere il disco dalla rotazione. Per fare ci\u00f2, \u00e8 necessario apportare le modifiche necessarie al server, fermare le applicazioni e smontare il disco.<\/p>\n

L'amministratore di sistema di turno, durante il proprio turno di lavoro, \u00e8 responsabile del funzionamento dell'intero portale. Indaga sugli incidenti, si occupa delle riparazioni e aiuta gli sviluppatori a completare piccole attivit\u00e0. Non si occupa solo dei dischi rigidi.<\/p>\n

In passato, gli ingegneri dei data center comunicavano con gli amministratori di sistema tramite chat. Gli ingegneri inviavano link ai ticket Jira, l'amministratore li esaminava e teneva un registro del lavoro in un blocco note. Tuttavia, per tali compiti le chat sono scomode: le informazioni non sono strutturate e si perdono rapidamente. Inoltre, l'amministratore poteva semplicemente allontanarsi dal computer e non rispondere alle richieste per un certo periodo, mentre l'ingegnere aspettava accanto al server con un pacco di dischi.<\/p>\n

Ma la cosa peggiore era che gli amministratori non vedevano il quadro generale: quali incidenti relativi ai dischi esistevano e dove potevano potenzialmente sorgere problemi. Questo \u00e8 dovuto al fatto che tutti gli incidenti HW vengono gestiti dagli ingegneri. S\u00ec, sarebbe stato possibile visualizzare tutti gli incidenti nella dashboard dell'amministratore. Ma ce ne sono troppi, e l'amministratore veniva coinvolto solo in alcuni di essi.<\/p>\n

Inoltre, l'ingegnere non poteva stabilire correttamente le priorit\u00e0, perch\u00e9 non sapeva nulla riguardo allo scopo dei singoli server e alla distribuzione delle informazioni sui dischi.<\/p>\n

Nuova procedura di sostituzione<\/h3>\n

\nLa prima cosa che abbiamo fatto \u00e8 stata separare tutti gli incidenti relativi ai disco in un tipo specifico chiamato \u00abHW-disco\u00bb e aggiungere i campi \u00abnome del dispositivo a blocchi\u00bb, \u00abdimensione\u00bb e \u00abtipo di disco\u00bb, in modo che queste informazioni vengano conservate nel ticket, evitando di doverle continuamente scambiare in chat. <\/p>\n

\"Automazione
\nInoltre, abbiamo concordato che all'interno di un singolo incidente verr\u00e0 sostituito solo un disco. Questo ha semplificato notevolmente in seguito il processo di automazione, la raccolta di statistiche e il lavoro. <\/p>\n

In aggiunta, abbiamo aggiunto il campo \u00abamministratore responsabile\u00bb. In questo campo viene automaticamente inserito il sistemista di turno. \u00c8 molto comodo, perch\u00e9 ora l'ingegnere vede sempre chi \u00e8 responsabile. Non \u00e8 necessario controllare il calendario alla ricerca. Proprio questo campo ha permesso di portare nella dashboard dell'amministratore i ticket in cui potrebbe essere necessaria la sua assistenza.<\/p>\n

\"Automazione
\nPer garantire che tutti i partecipanti possano trarre il massimo beneficio dalle innovazioni, abbiamo creato filtri e dashboard, e li abbiamo presentati ai ragazzi. Quando le persone comprendono i cambiamenti, non si allontanano da essi come da qualcosa di superfluo. Per un ingegnere \u00e8 importante sapere il numero del rack in cui si trova il server, le dimensioni e il tipo di disco. Un amministratore deve prima di tutto capire di che gruppo di server si tratta e quale pu\u00f2 essere l'effetto della sostituzione del disco.<\/p>\n

Avere dei campi e la loro visualizzazione \u00e8 comodo, ma non ci ha liberato dalla necessit\u00e0 di utilizzare le chat. Per questo abbiamo dovuto modificare il flusso di lavoro. <\/p>\n

Prima era cos\u00ec:<\/p>\n

\"Automazione
\nOggi gli ingegneri continuano a lavorare in questo modo, quando non hanno bisogno dell'aiuto di un amministratore.<\/p>\n

La prima cosa che abbiamo fatto \u00e8 stata introdurre un nuovo stato Investigate<\/b>. In questo stato il ticket si trova Quando l'ingegnere non ha ancora deciso se avr\u00e0 bisogno di un amministratore o meno. Attraverso questo stato, l'ingegnere pu\u00f2 trasferire il ticket all'amministratore. Inoltre, usiamo questo stato per contrassegnare i ticket quando \u00e8 necessaria la sostituzione del disco, ma il disco stesso non \u00e8 disponibile in sede. Questo accade nel caso di CDN e sites remoti.<\/p>\n

Abbiamo anche aggiunto uno stato Pronto<\/b>. Il ticket viene trasferito dopo la sostituzione del disco. Cio\u00e8, tutto \u00e8 gi\u00e0 stato fatto, ma il RAID HW\/SW \u00e8 in sincronizzazione sul server. Questo pu\u00f2 richiedere parecchio tempo.<\/p>\n

Se \u00e8 coinvolto un amministratore, lo schema diventa un po' pi\u00f9 complesso.<\/p>\n

\"Automazione
\nDallo stato Aperto<\/b> il ticket pu\u00f2 essere trasferito sia da un amministratore di sistema che da un ingegnere. Nell stato In corso<\/b> l'amministratore estrae il disco dalla rotazione in modo che l'ingegnere possa semplicemente rimuoverlo: attiva l'illuminazione, smonta il disco, ferma le applicazioni, a seconda del particolare gruppo di server.<\/p>\n

Poi il ticket viene trasferito in Pronto per la sostituzione<\/b>: questo \u00e8 un segnale per l'ingegnere che il disco pu\u00f2 essere estratto. Tutti i campi in Jira sono gi\u00e0 compilati, e l'ingegnere sa quale tipo e dimensione di disco. Questi dati vengono inseriti automaticamente nello stato precedente o dall'amministratore.<\/p>\n

Dopo la sostituzione del disco, il ticket viene trasferito nello stato Modificato<\/b>. Si verifica che sia stato inserito il disco corretto, vengono effettuate le etichette, viene avviata l'applicazione e alcune attivit\u00e0 di ripristino dei dati. Inoltre, il ticket pu\u00f2 essere trasferito nello stato Pronto<\/b>, in questo caso l'amministratore rimarr\u00e0 responsabile, poich\u00e9 \u00e8 stato lui a inserire il disco nella rotazione. Lo schema completo appare cos\u00ec.<\/p>\n

\"Automazione
\nL'aggiunta di nuovi campi ha reso la nostra vita molto pi\u00f9 facile. I ragazzi ora lavorano con informazioni strutturate, ed \u00e8 chiaro cosa e in quale fase deve essere fatto. Le priorit\u00e0 sono diventate molto pi\u00f9 rilevanti, poich\u00e9 ora vengono stabilite dall'amministratore.<\/p>\n

Non c'\u00e8 pi\u00f9 bisogno di chat. Certo, l'amministratore pu\u00f2 chiedere all'ingegnere \"qui bisogna sostituire pi\u00f9 rapidamente\" o \"\u00e8 gi\u00e0 sera, riesci a sostituire?\". Ma non ci comunichiamo pi\u00f9 quotidianamente su queste questioni nelle chat.<\/p>\n

I dischi sono stati sostituiti in blocchi. Se l'amministratore arriva al lavoro un po' prima, ha del tempo libero e non \u00e8 successo nulla, pu\u00f2 preparare una serie di server per la sostituzione: impostare i campi, rimuovere i dischi dalla rotazione e trasferire il compito all'ingegnere. L'ingegnere arriva un po' dopo nel data center, vede il compito, prende i necessari dispositivi dal magazzino e li sostituisce immediatamente. Di conseguenza, la velocit\u00e0 della sostituzione \u00e8 aumentata.<\/p>\n

Le esperienze acquisite nella costruzione del Workflow<\/h3>\n

<\/p>\n