Come può un team di devops dare la giusta priorità alla risoluzione dei problemi in arrivo rispetto alla creazione di un nuovo codice?

If you're working in a structure like this, how do you establish what to prioritise, what to defer?

Allo stesso modo in cui si dà la priorità a qualsiasi altra cosa: si sceglie sempre l'azione che massimizza il vantaggio rispetto al costo. Se c'è un bug che ha una risoluzione facile in cui sono in esecuzione molti utenti, correggilo prima. Se c'è una funzione interessante all'orizzonte che non impiegherà molto tempo per essere implementata, fallo dopo. Quindi considera i bug rari e le funzionalità difficili da implementare che non sono terribilmente eccitanti.

Facing a queue of two tickets, or ten tickets, or one hundred tickets, the application team has to decide what to do first.

Direi che non è compito del team delle applicazioni eseguire questa operazione se non in un modo tattico di livello molto basso, ad es. "Problema critico, lascia tutto ora." "Faremo questi due bug insieme perché sono nello stesso modulo." "Ripareremo questi difetti contemporaneamente all'aggiunta di questa funzionalità perché si trova in un'area correlata."

If you're working in a structure like this, how do you establish what to prioritise, what to defer?

Parli al business. Ci dovrebbe essere un regolare (con quale frequenza dipende dal volume del lavoro in arrivo - cercare di farlo abbastanza spesso per finire in circa un'ora) incontro prioritario con i rappresentanti del business con abbastanza autorità per approvare e fornire priorità a bug e funzionalità.

Penso che tu abbia evidenziato perfettamente il problema con l'approccio "lo hai scritto, lo aggiusti". (anche se non sono sicuro che sia completamente la stessa cosa di "devops")

Ovviamente nelle aziende di qualsiasi dimensione non è usuale per gli sviluppatori essere in grado di scegliere su quali biglietti lavorare. Normalmente hai un project manager o un simile che dà priorità alle attività in ordine di importanza per il business, non in ordine di importanza per lo sviluppatore.

Quindi se "scrivi un bug" non puoi correggerlo, a meno che non sia stato impostato come prioritario e ti capita di raccogliere l'attività successiva in coda.

Sebbene questo approccio dovrebbe motivare gli sviluppatori a scrivere sistemi di facile manutenzione, in realtà significa semplicemente che fanno anche il lavoro di helpdesk / supporto / operazioni, riavviando i box su cui non hanno lavorato e non avere il potere di cambiare.

Ovviamente il business paga per il loro tempo, e ci sono sempre alcuni sviluppatori che vogliono il denaro extra per le chiamate e sono felici di fare i turni.

Operazioni e manutenzione (O & M) mescolate a nuovi sviluppi non sono un nuovo problema. DevOps non cambia fondamentalmente come l'azienda dà la priorità al lavoro. Tuttavia, un buon approccio DevOps ti fornirà più feedback per triage in modo intelligente i problemi e discuterà su come architettare correttamente il problema dal tuo progetto.

Hai diversi livelli di eventi O & M che richiedono una risposta diversa:

• L'applicazione è morta : si tratta di un evento "tutto mani" che richiede una "sala guerra" per collaborare e ottenere il backup e l'esecuzione dell'applicazione più rapidamente possibile. La soluzione qui non è mai ottimale, ma l'azienda deve capire cosa è successo in modo da poter progettare una soluzione migliore e dare la priorità nel registro posteriore. Quando l'applicazione non funziona, la società non sta facendo soldi.
• Impatto principale : quando un problema interessa un ampio gruppo di utenti, potrebbe essere necessario eseguire il rollback del rilascio che ha introdotto il problema e tornare al tavolo da disegno. Se stai praticando DevOps questo dovrebbe essere possibile.
• Numerosi messaggi di errore nei log : molte volte ciò può accadere e gli utenti non sono direttamente interessati. Potrebbe essere che i messaggi di registro riportino le cose come errori che non sono errori, o potrebbe essere che il sistema rilasci informazioni a causa degli errori. Il problema deve essere identificato, aggiunto al backlog e priorizzato accanto alle nuove funzionalità.
• Perdita intermittente delle prestazioni : raccogli più informazioni possibili, individua il problema, aggiungilo al backlog e assegna la priorità alle nuove funzionalità.

Una cosa che è abbastanza possibile, in particolare con le applicazioni che si interrompono automaticamente, è che ci sono diversi rapporti sullo stesso problema. È responsabilità del personale di O & M sollevare il problema effettivo e riportare alcune statistiche sul numero di utenti interessati. Di nuovo, questo ha la priorità con le nuove funzionalità.

Arrivare al punto in cui questo processo è lineare richiede tempo. Probabilmente dovrai rinforzare il personale di O & M, e possibilmente introdurre più strumenti di monitoraggio. Avendo più livelli di supporto è possibile specializzare parte del personale di supporto per analizzare i report degli strumenti di monitoraggio e fornire feedback sulla salute del sistema e dove è debole. Le informazioni fornite da questo gruppo di membri di O & M evidenziano le aree in cui il design non è ben adattato con l'applicazione nel suo complesso. I problemi sono più profondi e richiedono un po 'più di riflessione su come risolvere in modo appropriato. Lavorerebbero a stretto contatto con il team di sviluppo per dare un senso alle informazioni e assistere nella pianificazione.

Un metodo consiste nell'utilizzare un software di segnalazione degli errori. Come testare il software, tiene traccia degli errori e fornisce report che possono essere usati per dare priorità ai bug per sviluppare un modo per tenere traccia delle correzioni dei difetti. Questo può fornirti il tracciamento di cui hai bisogno e ti consente anche di scegliere gli errori da rinviare a causa dell'impatto o delle risorse limitati. È possibile incorporare i report in un sistema di ordini di lavoro o nel proprio sistema di pianificazione delle risorse per l'assegnazione. Esempi di questo tipo di software sono Applications Manager, Datadog e Bugsnag .