vedligeholdelsesvinduer: Never Never Land of Patching

vedligeholdelsesvinduer er et koncept, der kan være vanskeligt at forstå fuldt ud i starten. Jeg er for doven til endda at prøve at hjælpe dig der, så hvis du har brug for noget ‘splainin, foreslår jeg, at du først går over til docs og Jason Sandys fremragende gennemgang.

før vi kommer ind i det, selvom jeg hurtigt vil rant om en ting først. Vedligeholdelsesvinduer kan kun reducere din patch-overholdelse. Brug dem, fordi der er en reel liv og/eller business truende grund til at gøre det. Hvis du bare skal sørge for, at patches/applikationer/opgavesekvenser installeres på en bestemt dato eller tid … er det, hvad implementeringsfrister er til.
ok, ud af sæbeboksen. Der er to krav, jeg har set ofte spurgt om, at jeg bruger vedligeholdelsesvinduer til at løse. Denne uge skal vi bare tackle den første:

Jeg vil aldrig, nogensinde, have dig til at lappe denne boks

hvis du har fulgt sammen med min blog eller talt med mig i selv den korteste tid, vil du genkende, hvor smertefuld den overskrift var at skrive. Det brænder. Patching er for vigtigt at overlade til os kødposer og bør automatiseres så meget som muligt. Der er dog visse situationer, hvor der findes en legitim grund til ikke at automatisere patching og genstart (hvilket er det samme). Disse situationer har tendens til at være på serversiden af ting, hvor arbejdsbyrder skal flyttes rundt (f.eks. Men der er også nogle tilfælde af arbejdsstation. Hvis du har arbejdsstationer i et operationsstue, får du et pass på automatisk opdatering af dem. I det mindste mens jeg er på bordet tak. Dine vinduer 2000 boks kører en atomreaktor er nok også fint. Lad være med at cykle den ting.

der er en række løsninger på dette problem, men for at være helt ærlig findes den eneste gode ikke: Support tilgængelige implementeringer til ADR ‘ er. Indtil da er den løsning, jeg bedst kan lide og efter min mening er den mest pålidelige, at skabe det, jeg kalder et ‘aldrig’ vedligeholdelsesvindue. Opret et ikke-tilbagevendende vedligeholdelsesvindue, der opstod tidligere. Det skulle ende med at se sådan ud:

dette fungerer, fordi når en enhed har et enkelt vedligeholdelsesvindue, fungerer det ikke uden for det. Hvis det enkelte vedligeholdelsesvindue er i fortiden og ikke gentager sig selv, vil intet nogensinde automatisk installere på den enhed igen. I stedet, når en implementeringsfrist rammer, vil den forsøge at installere, opdage, at den i øjeblikket ikke er inden for et vedligeholdelsesvindue, og permanent rapportere sig selv som ‘forfalden’ og vente på et vedligeholdelsesvindue, der aldrig kommer. Stakkels små opdateringer … så ensom. De vil altid forblive på den måde, indtil nogen åbner Programcenter og manuelt initierer installationen. Hvis du ønskede at få alle fancy-shmancy, kunne du udløse de manuelle installationer eksternt ved hjælp af en række teknikker, herunder <fuld shill-tilstand> noget som Højreklik-værktøjets installer manglende Programopdateringsværktøj </fuld shill-tilstand>.

der er to antagelser, der gøres her. Først: at du ikke implementerer noget, der tilsidesætter vedligeholdelsesvinduer. Der er ingen fastsættelse dum, så vær ikke dum. For det andet: at du ikke anvender et andet vedligeholdelsesvindue på enhederne i aldrig-samlingen. Denne er lidt vanskeligere og er en del af, hvorfor det næsten er universelt aftalt, at du skal oprette separate samlinger, der kun findes til vedligeholdelsesvinduesformål. Desuden anbefaler jeg stærkt at gøre det nemt at identificere dine vedligeholdelsesvinduer ved at sætte dem i en mappe og/eller præfiksere samlingerne med noget meningsfuldt. For eksempel: ‘mv – aldrig’. På denne måde ved du, hvor dine vedligeholdelsesvinduer er, og du kan sikre dig, at de alle udelukker dit aldrig vedligeholdelsesvindue. Hvis du sørger for, at hver vedligeholdelsesvinduesamling udelukker dit aldrig vedligeholdelsesvindue, garanterer du blot at tilføje enheder til dit aldrig vedligeholdelsesvindue, at du ikke krydser vandløbene:

et vedligeholdelsesvindue med fordele!

der er nogle frynsegoder ved at bruge en aldrig vedligeholdelse vindue, som du ikke får forsøger at løse dette problem andre måder.

for det første er brug af et aldrig vedligeholdelsesvindue en fantastisk måde at lette i fuldautomatisk patching. Har nogle teammedlemmer, der mener, at deres enheder er specielle små snefnug i stedet for kvæg klar til slagtning? Sæt deres enheder i en aldrig vedligeholdelsesvindue og implementere patches til dem normalt. Du får kontrol og rapportering, mens slutbrugeren får at undgå at skulle vente på vinduer Opdatere scanninger og opdateringer til at hente. Mine serveradministratorer elskede det faktum, at de kunne åbne Programcenter i løbet af dagen for at validere, hvilke programrettelser der ventede på at blive anvendt, før de loggede ind om aftenen for at anvende dem. De elskede også evnen til at script processen, så det kunne gøres manuelt, men uden at skulle logge ind på hver maskine. Afgørende, efter et stykke tid spurgte mange sig selv, hvorfor de stod op klokken for at trykke på en enkelt knap. Det gjorde automatiseret patching konverterer til gavn for computing race.

for det andet er dit aldrig vedligeholdelsesvindue en aftalt sortliste over enheder, der er døde for dig. Mit rapporteringsdashboard blev skrevet specifikt for at rapportere om servere globalt, servere med aktive vedligeholdelsesvinduer og servere med vinduet aldrig vedligeholdelse. Dette gjorde det muligt for mig at vise ledelsen, hvor forfærdelige nogle af mine kolleger administratorer var ved manuelt at lappe deres enheder, mens de også udelukkede dem fra de overholdelsesnumre, jeg var interesseret i. Når sikkerhed kom banke om en bestemt boks trin Et var at gennemgå Min aldrig vedligeholdelse vindue medlemskab for enheden(r) pågældende. Hvis de var der, fortalte jeg dem heldigvis at tage det op med appejere, der holdt fast ved manuel patching af deres egne enheder. Dette hjalp også med at skabe automatiserede patching-konvertitter … omend mindre villige.

endelig relateret til ovenstående var vinduet aldrig vedligeholdelse et udløb til at håndtere kumulative opdateringer, der kun påvirkede en lille delmængde af applikationer. Med kumulative opdateringer betyder det bare at blokere denne måneds patch, at de bare går i stykker igen, når næste måneds patches kommer ud, medmindre det underliggende problem er løst. Hvis en applikationsejer bad mig om ikke at lappe deres kasse, dirigerede jeg dem til vores CIO og krævede CIO ‘ s skriftlige godkendelse til at placere deres kasser i vinduet aldrig vedligeholdelse og … dette er den afgørende del … lappe aldrig disse kasser igen. Cirka 50% af sagerne kom aldrig forbi den del, og dem, der gjorde, var ikke længere mit problem, fordi de blev udelukket fra den rapportering, der betyder noget for mig.

så der har du det. Som sagt er der mere end en måde at løse dette krav på, men af ovenstående grunde er konceptet med et aldrig vedligeholdelsesvindue et, jeg konstant falder tilbage på som den bedste løsning, indtil produktteamet giver os tilgængelige implementeringer i ADR ‘ er. Selvom selv da, hvis du er bekymret for, at applikationer og opgavesekvenser ved et uheld bliver implementeret efter behov i stedet for tilgængelige, kan kun et vedligeholdelsesvindue garantere det.

Skriv et svar

Din e-mailadresse vil ikke blive publiceret.