IT Management

Juist: Een LAN ligt binnen één locatie, een WAN verbindt locaties over grotere afstand

Het onderscheid is afstand, niet techniek. Een LAN dekt één locatie — een kantoor, een gebouw. Een WAN knoopt locaties aan elkaar over grotere afstand; internet is het grootste WAN dat er is. Of het bekabeld of draadloos is zegt er niets over: een LAN kan allebei zijn.

Juist: Alleen de infrastructuur: servers, opslag en netwerk

IaaS levert de onderste laag: servers, opslag en netwerk. Het besturingssysteem en de applicaties zet je er zelf op, en die onderhoud je ook zelf. Bij SaaS krijg je juist het bovenste laagje — kant-en-klare software — en bemoei je je met niets eronder. Daartussen zit PaaS, waar je wel zelf bouwt maar de servers niet beheert.

Juist: Eerst authenticatie (wie ben je), daarna autorisatie (wat mag je)

Authenticatie komt eerst: het wachtwoord bewijst wie je bent. Pas daarna kijkt het systeem waar je bij mag, en dat is autorisatie — vandaar dat je alleen de mappen van je eigen afdeling ziet. De volgorde omdraaien kan niet: zolang niet vaststaat wie je bent, valt er niets toe te wijzen. Van twee factoren zou pas sprake zijn als er ná het wachtwoord nog een tweede bewijs van je identiteit werd gevraagd.

Juist: Een geprioriteerde lijst van wat er nog gebouwd moet worden

De backlog is de voorraadkast van het team: alles wat nog gebouwd moet worden, op volgorde van belang. Die volgorde is het punt — bovenaan staat wat het snelst waarde oplevert, en de product owner bepaalt dat. Gevonden fouten kunnen erin belanden, maar daar is de lijst niet voor bedoeld, en geschreven uren horen er helemaal niet in.

Juist: Een incident

Een incident is een onderbreking van de dienstverlening, en die printer doet het niet meer. Een probleem is de onderliggende oorzaak, en daar ga je pas naar op zoek als er meer meldingen binnenkomen: valt elke printer op die verdieping uit, dán heb je een probleem. De change is de wijziging die je daarna doorvoert, en het configuration item is de printer zoals hij in je registratie staat.

Juist: Wijzigingen gecontroleerd doorvoeren, zodat risico's en verstoringen beperkt blijven

Het gaat om beheerst wijzigen, niet om veel of snel wijzigen. Je weegt vooraf het risico, kiest een moment waarop de schade het kleinst is, en bedenkt hoe je terugkunt als het misgaat. Vastleggen welke onderdelen er zijn en hoe ze samenhangen is configuratiebeheer; toetsen of de afgesproken normen gehaald worden is service level management.

Juist: Er komt onvermijdelijk druk op tijd, geld of kwaliteit

Scope, tijd en geld hangen aan elkaar vast: trek je aan één hoek, dan beweegt er ergens anders iets mee. Komt er scope bij terwijl tijd en budget vastliggen, dan gaat de rek zitten in de kwaliteit — of het wordt alsnog later of duurder. Dat je er 'even iets bij doet' zonder gevolgen is precies de illusie waar dit model tegen waarschuwt.

Juist: CI voegt codewijzigingen samen en test ze automatisch; CD zet goedgekeurde wijzigingen automatisch naar productie

CI zit aan de voorkant: wijzigingen worden vaak samengevoegd en meteen automatisch getest, zodat je binnen een uur weet dat iets stuk is in plaats van pas na een maand. CD zet vervolgens automatisch naar productie wat die tests doorstaat. Het onderscheid heeft dus niets te maken met teamgrootte of met welke omgeving je gebruikt: het zijn twee opeenvolgende stappen in dezelfde straat.

Juist: De wijziging terugdraaien naar de vorige, werkende situatie

Terug naar de laatste stand die het deed — dat is het eerste wat je wilt bij een storing op productie, want de gebruiker heeft meer aan werkende software dan aan een verklaring. Waaróm het misging zoek je daarna uit, in probleembeheer. Escaleren kan er ook bij horen maar lost de storing zelf niet op, en de norm oprekken zodat de storing 'binnen de afspraak valt' is boekhouden, geen herstel.

Juist: Onderdelen kunnen apart ontwikkeld, geschaald en uitgerold worden

De winst zit in onafhankelijkheid: elk onderdeel heeft een eigen levenscyclus, dus een team kan uitrollen zonder op de rest te wachten, en je schaalt alleen het stuk dat het druk heeft. Die vrijheid koop je met complexiteit — juist tussen microservices heb je API's nodig, en meestal ook een eigen database per dienst in plaats van één centrale.