Come rispondere a un requisito di disponibilità del 100%
La domanda del committentePotete garantire una disponibilità del servizio del 100%?
Non trasformare un obiettivo di affidabilità in una garanzia di assenza di interruzioni. Indicare l'impegno approvato per il servizio effettivamente utilizzato dal committente. Se il 100% è obbligatorio e non negoziabile, una risposta con riserve non rende conforme l'offerta.
Una risposta da adattare
Non possiamo garantire disponibilità ininterrotta in qualsiasi circostanza. Per [servizio, ambiente di distribuzione e funzioni comprese], offriamo [impegno di disponibilità approvato], misurato su [periodo di misurazione] con [metodo concordato], fatte salve [esclusioni specifiche previste nelle condizioni proposte]. I rimedi in caso di mancato raggiungimento sono [rimedi approvati e riferimento contrattuale]. La proposta comprende [misure verificate di resilienza e ripristino], con perimetro e risultati dei test identificati in [riferimenti delle prove]. Gli impegni di ripristino sono indicati separatamente in [condizioni di ripristino approvate]; non costituiscono una promessa di assenza di interruzioni. Confermate tramite [canale autorizzato per i chiarimenti] se questo impegno definito è accettabile per il requisito [identificativo], oppure se una garanzia incondizionata del 100% è una condizione di ammissibilità.
Sostituisca ogni campo tra parentesi quadre con fatti verificati. Elimini le frasi facoltative che non può documentare. Non presenti questa formulazione senza adattarla.
Scheda dell'impegno di disponibilità
Prima di inserire una percentuale, riconciliare questi cinque elementi. Una discrepanza richiede verifica tecnica e approvazione commerciale, non una frase che la attenui.
- Che cosa conta come guasto?
- Specificare operazione utente non riuscita, soglia di interruzione e punto di misurazione. Una pagina di stato dell'infrastruttura non dimostra da sola il corretto funzionamento delle operazioni del committente da un'estremità all'altra.
- Su quale periodo?
- Indicare finestra temporale e fuso orario. Distinguere disponibilità basata sul tempo e percentuale di richieste riuscite: la stessa percentuale può descrivere esperienze molto diverse.
- Che cosa è escluso?
- Esplicitare manutenzione, guasti delle dipendenze e responsabilità del cliente. Verificare che il committente consenta tali esclusioni anziché copiare invariato il contratto standard.
- Che cosa si può dimostrare?
- Collegare architettura, copertura del monitoraggio e test di ripristino a questa opportunità. Una configurazione futura promessa va indicata come proposta, non già operativa.
- Che cosa succede se l'impegno non è rispettato?
- Registrare conseguenza negoziata e procedura di richiesta. Crediti, diritti di risoluzione ed esposizione economica richiedono approvazione; non li decide chi scrive l'offerta.
Le condizioni che sostengono la risposta
Distinguere una promessa assoluta di continuità da un impegno di servizio misurabile. Definire perimetro, prove ed eccezioni prima di rispondere.
Definire il servizio che il committente utilizzerà davvero
Identificare ambiente di produzione, operazioni comprese, orari di servizio e perimetro del monitoraggio. Un server funzionante non significa necessariamente un'applicazione utilizzabile. Stabilire se sono inclusi accesso, integrazioni, elaborazioni in background e connettività gestita dal committente. Non restringere implicitamente il requisito: ogni esclusione sostanziale deve comparire nella risposta e nelle condizioni proposte.
Tenere separati quattro impegni diversi
Obiettivo progettuale, disponibilità storica misurata, SLA contrattuale e obiettivo di ripristino rispondono a domande diverse. I risultati storici descrivono un periodo; lo SLA definisce obbligo approvato e rimedi. Gli obiettivi di tempo e punto di ripristino riguardano riattivazione e perdita di dati. Nessuno sostituisce automaticamente la disponibilità continua.
Lo SLA del fornitore infrastrutturale non è quello dell'applicazione
L'impegno del fornitore cloud vale per il suo servizio definito e per un'architettura che soddisfa le condizioni previste, non automaticamente per l'intera esperienza del cliente. Il Compute SLA di AWS, ad esempio, distingue impegni regionali e per istanza, con esclusioni e regole sui crediti di servizio. È un esempio per verificare i confini, non una prova dell'affidabilità del proprio prodotto.
La documentazione da acquisire
Condizioni di servizio approvate
Ottenere versione esatta dello SLA, definizione della misurazione, esclusioni, rimedi e ordine di prevalenza documentale. Registrare approvazione tecnica e legale delle deroghe all'offerta standard. Lasciare la percentuale non compilata finché queste informazioni non esistono.
Prove operative comparabili
Richiedere dati di monitoraggio relativi al perimetro offerto, periodo di riferimento e lacune note. Separare prestazione osservata e garantita. Includere gli incidenti pertinenti invece di scegliere soltanto il mese senza problemi.
Misure di continuità collaudate
Ottenere diagramma di distribuzione attuale, inventario delle dipendenze e risultati datati di ripristino o failover. Confermare oggetto dei test, guasti simulati ed eventuali azioni richieste al committente.
La decisione da approvare
- Responsabili dell’approvazione
- Ingegneria o il responsabile del servizio conferma la fattibilità; legale e autorità commerciale approvano l'obbligo. Il responsabile delle offerte registra la decisione di ammissibilità e conserva le riserve.
- Procedere
- Procedere con una risposta circoscritta solo se l'impegno è supportato, approvato e consentito dalle istruzioni del committente o da un chiarimento ufficiale applicabile.
- Non procedere
- Non rispondere Sì se significa accettare una garanzia senza interruzioni non dimostrabile. Se il requisito è obbligatorio e le alternative sono respinte, mantenere la lacuna e sottoporre la decisione sull'offerta ai responsabili.
- Richiedere una decisione
- Chiedere al committente di distinguere obiettivo di disponibilità, impegno contrattuale e requisito di continuità. Seguire il processo di quesiti consentito; non basarsi su rassicurazioni informali esterne a quel processo.
Conservare la decisione nei file da presentare
Prima del rilascio, verificare che la risposta finale conservi perimetro, percentuale ed esclusioni approvati e citi la revisione corretta dello SLA. REQVERA è uno strato di controllo finale per requisiti, risposte, prove approvate e file da presentare, non un garante di disponibilità o uno strumento di negoziazione delle eccezioni.
Vedere il flusso reale di controllo finaleAmbito e fonti di riferimento
Domanda illustrativa, non un caso cliente documentato. Pratica generale di risposta su impegni di disponibilità; non si afferma alcuno SLA o capacità di REQVERA. Efficacia contrattuale e condizioni obbligatorie di gara richiedono la pertinente verifica legale e di procurement.
- Google SRE: Service Level Objectives
Riferimento tecnico primario che distingue indicatori, obiettivi e accordi e mette in guardia dagli obiettivi assoluti di disponibilità. Non è uno SLA attuale di un prodotto Google.
- Amazon Compute Service Level Agreement
Esempio specifico del fornitore su impegni dipendenti dall'architettura, definizioni, esclusioni e rimedi. Non stabilisce lo SLA del fornitore che risponde.