Sidehistorik
Indholdsfortegnelse
Formål
For at man kan lave gode Changes og SOP'er (Standard Operating Procedures) er det ligesom at være en kok der skal lære at lave god mad, eller måske den matra man kører indenfor militæret - gentagelse, gentagelse, igen, igen..
...
| Advarsel |
|---|
Der er også datasikker- og datafortrolighed at tænke over, når udviklere gives nogen som helst form for adgang til Stage eller Prod, som ofte indeholder personhenførbar eller fortrolig data, både fordi at antallet af personer med tilgang simpelthen udviddes, sekundært fordi udvikleren [potentielt] har mulighed for at udnytte softwaren til at udtrække fortroligt data udenom normale foranstaltninger. End af udviklernes typiske grunde til at ænske eller begære adgang til Stage eller Produktion er kravet om at kunne debugge eller må logs i realtime, her anbefaler jeg produkter som splunk for at få data (på en kontrolleret måde) ned fra serverne/systemerne til udviklerne. Sekundært er der IT Revisionsmæssigt gode grunde til at funktionsadskille. |
...
Det kan derfor være ønskeligt at "rense" opskriften for disse ting og lave en SOP - hvor alle navngivninger er ændret i nomenklateren til placeholders for objekter etc. Det er så også ønskeligt at der med eller i SOP'en følger en forklaring og/eller liste af hvad der skal i disse placeholders når SOP'en bruges (Pre-requisite).
Det sidste skridt der derfor at SOP'en laves:
| Gliffy Diagram | ||||
|---|---|---|---|---|
|
Del og Hersk
Del og Hersk er et vigtigt princip for gode changes (og SOPs) - frem for at have en meget stor Change med mange skridt og implementationstyper (Applikation, Firewall, Database, OS) bør man dele Changen op i flere af hinanden enten uafhængige eller sekventielle Changes der hver for sig kan gennemføres. Dette betyder også at et evt. rollback af en Change ikke er så kristisk for den samlede masse af Changes.