Ontwerpprincipes voor betrouwbaarheid
Storingen en storingen zijn ernstige problemen voor alle workloads. Een betrouwbare workload moet deze gebeurtenissen overleven en de beoogde functionaliteit consistent blijven bieden. Het moet robuust zijn, zodat het fouten binnen een acceptabele periode kan detecteren, weerstaan en herstellen. Het moet ook beschikbaar zijn zodat gebruikers toegang hebben tot de workload tijdens de beloofde periode op het beloofde kwaliteitsniveau.
Het is niet realistisch om aan te nemen dat er geen fouten optreden, met name wanneer de workload is gebouwd om te worden uitgevoerd op gedistribueerde systemen. Sommige onderdelen kunnen mislukken terwijl andere blijven werken. Op een bepaald moment kan de gebruikerservaring worden beïnvloed, wat de bedrijfsdoelen in gevaar brengt.
Workloadarchitecturen moeten betrouwbaarheidsgaranties hebben in toepassingscode, infrastructuur en bewerkingen. Ontwerpkeuzen mogen de intentie die is opgegeven door bedrijfsvereisten niet wijzigen. Dergelijke wijzigingen moeten worden beschouwd als aanzienlijke compromissen.
De ontwerpprincipes zijn bedoeld om richtlijnen te bieden voor aspecten van betrouwbaarheid waarmee u rekening moet houden tijdens de ontwikkelingslevenscyclus. Begin met de aanbevolen benaderingen en rechtvaardig de voordelen voor een set vereisten. Nadat u uw strategie hebt ingesteld, kunt u acties stimuleren met behulp van de controlelijst voor betrouwbaarheid.
Als u deze principes niet toepast op uw ontwerp, is de workload waarschijnlijk niet voorbereid op het anticiperen of afhandelen van problemen in productie. Het resultaat kan serviceonderbrekingen zijn die leiden tot financiële verliezen. In het geval van kritieke workloads kan het niet toepassen van deze principes de veiligheid in gevaar brengen.
Ontwerpen voor bedrijfsvereisten
Verzamel bedrijfsvereisten met de focus op het beoogde hulpprogramma van de workload. |
---|
Vereisten moeten betrekking hebben op de gebruikerservaring, gegevens, werkstromen en kenmerken die uniek zijn voor de workload. Het resultaat van het vereistenproces moet duidelijk de verwachtingen aangeven. De doelstellingen moeten haalbaar zijn en worden onderhandeld met het team, op basis van een bepaalde investering. Ze moeten worden gedocumenteerd om technologische keuzes, implementaties en bewerkingen te stimuleren.
Methode | Voordeel |
---|---|
Het succes kwantificeren door doelen in te stellen op indicatoren voor afzonderlijke onderdelen, systeemstromen en het systeem als geheel. Maken deze doelen gebruikersstromen betrouwbaarder? | Metrische gegevens kwantificeren de verwachtingen. Hiermee kunt u complexe aspecten begrijpen en bepalen of de downstreamkosten van deze complexiteiten binnen de investeringslimiet vallen. De doelwaarden geven een ideale status aan. U kunt de waarden gebruiken als testdrempelwaarden waarmee u afwijkingen van die status kunt detecteren en hoe lang het duurt om terug te keren naar de doelstatus. Nalevingsvereisten moeten ook voorspelbare resultaten hebben voor stromen binnen het bereik. Het prioriteren van deze stromen brengt de aandacht naar gebieden die het meest gevoelig zijn. |
Informatie over platformtoezeggingen. Houd rekening met de limieten, quota, regio's en capaciteitsbeperkingen voor services. | Service level agreements (SLA's) verschillen per service. Niet alle services en functies worden even goed behandeld. Niet alle services of functies zijn beschikbaar in alle regio's. De meeste abonnementsresourcelimieten zijn per regio. Als u een goed begrip hebt van dekking en limieten , kunt u afwijkingen detecteren en tolerantie- en herstelmechanismen bouwen. |
Afhankelijkheden en hun effect op de tolerantie bepalen. | Als u afhankelijke infrastructuur, services, API's en functies bijhoudt die zijn ontwikkeld door andere teams of derden, kunt u bepalen of de workload kan worden uitgevoerd zonder deze afhankelijkheden. Het helpt u ook om trapsgewijze fouten te begrijpen en downstreambewerkingen te verbeteren. Ontwikkelaars kunnen tolerante ontwerppatronen implementeren om potentiële fouten af te handelen wanneer u externe services gebruikt die vatbaar zijn voor fouten. |
Ontwerpen voor tolerantie
De workload moet blijven werken met volledige of verminderde functionaliteit. |
---|
U moet verwachten dat er storingen in onderdelen, platformstoringen, prestatieverminderingen, beperkte beschikbaarheid van resources en andere fouten optreden. Bouw tolerantie in het systeem in, zodat het fouttolerant is en probleemloos kan degraderen.
Methode | Voordeel |
---|---|
Onderscheid tussen onderdelen die zich op het kritieke pad bevinden van onderdelen die in een gedegradeerde status kunnen functioneren. | Niet alle onderdelen van de workload hoeven even betrouwbaar te zijn. Het bepalen van de ernst helpt u bij het ontwerpen op basis van de ernst van elk onderdeel. U overstuurt de tolerantie niet voor onderdelen die de gebruikerservaring enigszins kunnen verslechteren, in tegenstelling tot onderdelen die end-to-end problemen kunnen veroorzaken als ze mislukken. Het ontwerp kan efficiënt zijn bij het toewijzen van resources aan kritieke onderdelen. U kunt ook strategieën voor foutisolatie implementeren, zodat als een niet-kritiek onderdeel uitvalt of een gedegradeerde status krijgt, het kan worden geïsoleerd om trapsgewijze fouten te voorkomen. |
Identificeer mogelijke foutpunten in het systeem, met name voor de kritieke onderdelen, en bepaal het effect op gebruikersstromen. | U kunt de foutgevallen, de straal van de explosie en de intensiteit van de fout analyseren: volledige of gedeeltelijke storing. Deze analyse is van invloed op het ontwerp van de mogelijkheden voor foutafhandeling op onderdeelniveau. |
Bouw mogelijkheden voor zelfbehoud door op de juiste wijze ontwerppatronen te gebruiken en het ontwerp te modulariseren om fouten te isoleren. | Het systeem kan voorkomen dat een probleem downstreamonderdelen beïnvloedt. Het systeem kan tijdelijke en permanente fouten, prestatieknelpunten en andere problemen oplossen die van invloed kunnen zijn op de betrouwbaarheid. U kunt ook de straal van de ontploffing minimaliseren. |
Voeg de mogelijkheid toe om de kritieke onderdelen (toepassing en infrastructuur) uit te schalen door rekening te houden met de capaciteitsbeperkingen van services in de ondersteunde regio's. | De workload kan variabele capaciteitspieken en schommelingen verwerken. Deze mogelijkheid is van cruciaal belang wanneer het systeem onverwacht wordt belast, zoals een piek in geldig gebruik. Als de workload is ontworpen om uit te schalen over meerdere regio's, kan deze zelfs potentiële tijdelijke beperkingen van resourcecapaciteit of andere problemen oplossen die van invloed zijn op één regio. |
Bouw redundantie in lagen en tolerantie in verschillende toepassingslagen. Streven naar redundantie in fysieke hulpprogramma's en onmiddellijke gegevensreplicatie. U kunt ook streven naar redundantie in de functionele laag die betrekking heeft op services, bewerkingen en personeel. |
Redundantie helpt bij het minimaliseren van Single Points of Failure. Als er bijvoorbeeld een onderdeel, zonegebonden of regionale storing is, kunt u met redundante implementatie (in actief-actief of actief-passief) voldoen aan de uptime-doelen. Het toevoegen van tussenschakels voorkomt directe afhankelijkheid tussen onderdelen en verbetert de buffering. Beide voordelen verbeteren de tolerantie van het systeem. |
Overprovision om direct individuele fouten van redundante exemplaren te beperken en om te bufferen tegen runaway resourceverbruik. | Hogere investeringen in overprovisioning verhogen de tolerantie. Het systeem blijft werken met volledig hulpprogramma tijdens een actieve fout, zelfs voordat schaalbewerkingen kunnen beginnen met het oplossen van de fout. Op dezelfde manier kunt u het risico verminderen van onverwacht op hol geslagen resourceverbruik door uw geplande buffer te claimen, waardoor kritieke sorteertijd ontstaat voordat systeemfouten of agressieve schaalaanpassingen optreden. |
Ontwerpen voor herstel
De workload moet kunnen anticiperen op en herstellen van de meeste fouten, van alle omvang, met minimale onderbreking van de gebruikerservaring en bedrijfsdoelstellingen. |
---|
Zelfs zeer tolerante systemen hebben noodparaatheidsmethoden nodig, zowel in architectuurontwerp als workloadbewerkingen. Op de gegevenslaag moet u strategieën hebben die de workloadstatus kunnen herstellen in geval van beschadiging.
Methode | Voordeel |
---|---|
Beschikken over gestructureerde, geteste en gedocumenteerde herstelplannen die zijn afgestemd op de overeengekomen hersteldoelen. Plannen moeten alle onderdelen omvatten naast het systeem als geheel. | Een goed gedefinieerd proces leidt tot een snel herstel dat negatieve gevolgen voor de financiën en reputatie van uw bedrijf kan voorkomen. Het uitvoeren van regelmatige herstelanalyses test het proces van het herstellen van systeemonderdelen, gegevens en failover- en failbackstappen om verwarring te voorkomen wanneer tijd en gegevensintegriteit belangrijke maatstaven voor succes zijn. |
Zorg ervoor dat u gegevens van alle stateful onderdelen binnen uw hersteldoelen kunt herstellen. | Back-ups zijn essentieel om het systeem weer in een werkende staat te krijgen met behulp van een vertrouwd herstelpunt, zoals de laatst bekende goede status. Onveranderbare en transactioneel consistente back-ups zorgen ervoor dat gegevens niet kunnen worden gewijzigd en dat de herstelde gegevens niet beschadigd zijn. |
Implementeer geautomatiseerde mogelijkheden voor zelfherstel in het ontwerp. | Deze automatisering vermindert de risico's van externe factoren, zoals menselijke tussenkomst, en verkort de break-fix-cyclus. |
Vervang staatloze onderdelen door onveranderbare tijdelijke eenheden. | Het bouwen van tijdelijke eenheden die u op aanvraag kunt instellen en vernietigen, biedt herhaalbaarheid en consistentie. Gebruik implementatiemodellen naast elkaar om de overgang naar de nieuwe eenheden incrementeel te maken, waardoor onderbrekingen tot een minimum worden beperkt. |
Ontwerp zodat bewerkingen eenvoudig kunnen worden uitgevoerd
Schuif naar links in bewerkingen om te anticiperen op foutomstandigheden. |
---|
Test fouten vroeg en vaak in de ontwikkelingslevenscyclus en bepaal de impact van prestaties op de betrouwbaarheid. Ten behoeve van de hoofdoorzaakanalyse en postmortems moet u gedeelde zichtbaarheid hebben, tussen teams, van de afhankelijkheidsstatus en lopende fouten. Inzichten, diagnostische gegevens en waarschuwingen van waarneembare systemen zijn essentieel voor effectief incidentbeheer en continue verbetering.
Methode | Voordeel |
---|---|
Bouw waarneembare systemen die telemetrie kunnen correleren. | Bewaking en diagnose zijn cruciale bewerkingen. Als er iets mislukt, moet u weten dat het is mislukt, wanneer het is mislukt en waarom het is mislukt. Waarneembaarheid op onderdeelniveau is essentieel, maar geaggregeerde waarneembaarheid van onderdelen en gecorreleerde gebruikersstromen biedt een holistische weergave van de status. Deze gegevens zijn vereist om sitebetrouwbaarheidstechnici in staat te stellen prioriteit te geven aan hun inspanningen voor herstel. |
Mogelijke storingen en afwijkend gedrag voorspellen. Actieve betrouwbaarheidsfouten zichtbaar maken met behulp van waarschuwingen met prioriteit en waarvoor actie kan worden uitgevoerd. Investeer in betrouwbare processen en infrastructuur die leiden tot snellere sortering. |
Technici voor site betrouwbaarheid kunnen onmiddellijk op de hoogte worden gesteld, zodat ze lopende livesite-incidenten kunnen beperken en potentiële fouten die worden geïdentificeerd door voorspellende waarschuwingen proactief kunnen beperken voordat ze live-incidenten worden. |
Simuleer fouten en voer tests uit in productie- en preproductieomgevingen. | Het is handig om fouten in de productie te ervaren, zodat u realistische verwachtingen voor herstel kunt instellen. Hierdoor kunt u ontwerpkeuzen maken die probleemloos reageren op fouten. Ook kunt u hiermee de drempelwaarden testen die u hebt ingesteld voor metrische bedrijfsgegevens. |
Bouw onderdelen met automatisering in het achterhoofd en automatiseer zoveel mogelijk. | Automatisering minimaliseert de kans op menselijke fouten en zorgt voor consistentie in testen, implementatie en bewerkingen. |
Houd rekening met routinebewerkingen en hun invloed op de stabiliteit van het systeem. | De workload kan onderhevig zijn aan lopende bewerkingen, zoals toepassingsrevisies, beveiligings- en nalevingscontroles, onderdeelupgrades en back-upprocessen. Het onderzoeken van deze wijzigingen zorgt voor de stabiliteit van het systeem. |
Leer continu van incidenten in productie. | Op basis van de incidenten kunt u de impact en het toezicht in het ontwerp en de bewerkingen bepalen die mogelijk onopgemerkt zijn in de preproductie. Uiteindelijk kunt u verbeteringen aanbrengen op basis van echte incidenten. |
Houd het eenvoudig
Vermijd overengineering van het architectuurontwerp, de toepassingscode en bewerkingen. |
---|
Het is vaak wat u verwijdert in plaats van wat u toevoegt, dat leidt tot de meest betrouwbare oplossingen. Eenvoud vermindert de oppervlakte voor controle, waardoor inefficiënties en mogelijke onjuiste configuraties of onverwachte interacties worden geminimaliseerd. Aan de andere kant kan oversimplificatie single points of failure veroorzaken. Zorg voor een evenwichtige aanpak.
Methode | Voordeel |
---|---|
Voeg alleen onderdelen toe aan uw architectuur als ze u helpen om bedrijfsdoelwaarden te bereiken. Houd het kritieke pad lean. | Ontwerpen voor bedrijfsvereisten kan leiden tot een eenvoudige oplossing die eenvoudig te implementeren en te beheren is. Vermijd te veel kritieke onderdelen, omdat elk onderdeel een belangrijk foutpunt is. |
Stel standaarden in code-implementatie, implementatie en processen vast en documenteer deze. Mogelijkheden identificeren om deze standaarden af te dwingen met behulp van geautomatiseerde validaties. | Standaarden bieden consistentie en minimaliseren menselijke fouten. Benaderingen zoals standaardnaamconventies en handleidingen voor codestijlen kunnen u helpen de kwaliteit te behouden en assets gemakkelijk te identificeren tijdens het oplossen van problemen. |
Evalueer of theoretische benaderingen worden omgezet in een pragmatisch ontwerp dat van toepassing is op uw use cases. | Toepassingscode die te gedetailleerd is, kan leiden tot onnodige onderlinge afhankelijkheid, extra bewerkingen en moeilijk onderhoud. |
Ontwikkel net genoeg code. | U kunt problemen voorkomen die het gevolg zijn van inefficiënte implementaties, zoals onverwacht resourceverbruik, gebruikers- of gegevensstroomfouten en codefouten. Betrouwbaarheidsproblemen moeten daarentegen leiden tot codebeoordelingen om ervoor te zorgen dat code tolerant genoeg is om de problemen af te handelen. |
Profiteer van platformfuncties en vooraf gebouwde assets die u kunnen helpen bij het effectief behalen van bedrijfsdoelen. | Deze aanpak minimaliseert de ontwikkeltijd. Hiermee kunt u ook vertrouwen op beproefde procedures die zijn gebruikt met vergelijkbare workloads. |