Automation: Impact op jouw omgeving

[Verwijderd]

Het zal de meeste beheerders niet ontgaan zijn en degene die er nog nooit over hebben gehoord zullen er vroeg of laat toch te maken mee krijgen: Automation.

Door de grote efficientie slagen die je kan maken als beheerder met een dergelijk pakket en daardoor een enorme impact het heeft bij organisaties en in de ICT wereld op grote en kleine schaal. Wilde ik deze discussie starten om te kijken wat jullie visie is op de komst van automation en de impact die het heeft voor jouw werk, organisatie en natuurlijk voor jouwzelf voor de korte en lange termijn.

Kortom, hoe denken jullie over automation?

Kleine FAQ:

- Wat is automation?
Automation is domweg het efficient automatiseren van repeterend werk.

- Waar kan je automation voor gebruiken ?
Van bijvoorbeeld gestandariseerd lifecycle en/of patch management van systemen tot aan specifieke repeterend applicatieve taken Denk aan bijvoorbeeld een geautomatiseerd compileren van broncode en/of het bouwen van installatiepakketten.

- Aan wat voor pakketten moet ik dan aan denken?
Vanuit een beheerders perspectief zijn dat bijvoorbeeld pakketten zoals Ansible, CFengine, Puppet of System Center Suite.

[Razwer]

zeker een linux beheerder?
System Center is bij uitstek het pakket op Windows voor automation.
Dat werkt hand in hand met Powershell. Soms ook niet en dan mag je zelf knutselen met powershell
Broncode compileren doet de gemiddelde Windows beheerder niet.

[ Voor 45% gewijzigd door Razwer op 23-03-2015 09:33 ]

[Verwijderd]

Razwer, Puppet en Ansible werkt ook op Windows en kan je ook MSI pakketten laten bouwen.

[CMD-Snake]

Voor het Windows platform heb je voornamelijk de System Center suite. Orchestrator verzorgt de automation daar en kan de diverse andere onderdelen van de suite samenbrengen. Orchestrator is behoorlijk flexibel, van de vele integration packs tot aan objecten die je zelf kan maken.

Het is behoorlijk effectief als je alle System Center pakketten met elkaar integreert. Veel zaken kunnen dan via self service portals en runbooks in Orchestrator afgehandeld worden.

Patch management automatiseren kan prima in SCCM 2012. Je kan rules aanmaken over hoe patches naar diverse collections worden uitgerold. Het werkt allemaal via het standaard Windows Update mechaniek. Persoonlijk vind ik dat de beste manier om Windows clients en servers te beheren en te voorzien updates.

[Verwijderd]

Oke, weer wat geleerd.

Maar even terug naar het onderwerp. Wat voor impact heeft automation voor jullie en hoe kijken jullie er tegenaan?

[Question Mark]

Verwijderd schreef op maandag 23 maart 2015 @ 09:25:
Kortom, hoe denken jullie over automation?

Ik mis even je eigen mening over automation. Wellicht handig dat je die als topicstarter ook nog even noemt om de discussie op weg te helpen.

Je geeft nu een globale omschrijving over wat jij vind wat automation is, maar je beantwoord eigenlijk niet de vragen die je stelt aan anderen.

[Razwer]

Verwijderd schreef op maandag 23 maart 2015 @ 09:35:
Razwer, Puppet en Ansible werkt ook op Windows en kan je ook MSI pakketten laten bouwen.

Dat ontkende ik ook niet, maar zoals CMD-Snake uitlegd is System Center met ster de nummer 1 op Windows gebied. Ik moest gewoon ff gniffelen toen ik jouw topic start las.
Het was gesproken als een echte Linux beheerder
Niks mis mee, maar er zijn vaak verschillen van denkwijze.

[Verwijderd]

Question Mark schreef op maandag 23 maart 2015 @ 11:30:
[...]

Ik mis even je eigen mening over automation. Wellicht handig dat je die als topicstarter ook nog even noemt om de discussie op weg te helpen.

Je geeft nu een globale omschrijving over wat jij vind wat automation is, maar je beantwoord eigenlijk niet de vragen die je stelt aan anderen.

En de reden dat ik niet niet gelijk mijn mening geef is omdat ik niet mijn mening wil etaleren en de discussie open wil houden. Het is niet omdat ik geen mening heb.

Maar om dan toch met de boot in huis te vallen: Wat is jouw mening over automation tot zover?

[ Voor 7% gewijzigd door Verwijderd op 23-03-2015 12:33 ]

[Powergrim]

Hier wordt RES- Automation Manager gebruikt. Heerlijk pakket wat perfect werkt voor Windows, en volgens mij met de juiste "plug-ins" ook wel met Linux kan praten.

Ik heb wat ervaring met SCCM, en hoewel dat ook lekker werkt, doet RES AM toch wel wat stabieler aanvoelen. Helaas kunnen we niet imagen met RES AM, dat gebeurd nu nog gewoon met MDT.

In de toekomst vervalt dat ook, dan hebben er RES Workspace manager. De enige image die we dan nog gebruiken is die van een thin client, en die heeft zijn eigen imaging tools.

Al met al, ik ben er blij mee. En hoewel het veel werk uit handen neemt brengt het ook veel werk om te beheren (het packagen alleen al bijvoorbeeld) met zich mee. Ik dus geen bedreiging voor mijn workload.

[Trommelrem]

Een hele belangrijke is natuurlijk PowerShell DSC!

[Question Mark]

Verwijderd schreef op maandag 23 maart 2015 @ 12:31:
[...]

En de reden dat ik niet niet gelijk mijn mening geef is omdat ik niet mijn mening wil etaleren en de discussie open wil houden. Het is niet omdat ik geen mening heb.

Dat vind ik een onzinnige reden. Waarom zou de discussie niet open blijven als jij je mening geeft? Ik verwacht dat je als topicstarter wel mee gaat doen aan de discussie, ander geef ik dit topic weinig kans.

Maar om dan toch met de boot in huis te vallen: Wat is jouw mening over automation tot zover?

Ik vind automation veel breder dan de korte samenvatting die je hier schetst. Automation is in mijn ogen niet het automatiseren van repeterend werk. Het is het uitvoeren van handelingen zonder menselijke interactie. Afhankelijk van een omgeving kunnen handelingen volledig voorgedefineerd zijn, en starten door middel van bepaalde triggers.

Een kamerthermostaat die op een bepaald tijdstip iets gaat doen is een vorm van (home)automation. Een SCOM server die een snmp trap verstuurd bij een bepaald event en als gevolg hiervan een script start is een vorm van procesautomatisering.

De impact is verschillend per persoon en afhankelijk van je huidige functie. Voor mij als "architect" zit hier een uitdaging, voor iemand op een servicedesk kan het een risico zijn.

Nu jij

[Verwijderd]

Question Mark schreef op maandag 23 maart 2015 @ 12:44:
Dat vind ik een onzinnige reden. Waarom zou de discussie niet open blijven als jij je mening geeft? Ik verwacht dat je als topicstarter wel mee gaat doen aan de discussie, ander geef ik dit topic weining kans.

Ik doe ook mee. Maar door mijn mening direct te geven beinvloed ik de discussie al bijvoorbaat. En dat is naar mijn optiek niet de bedoeling.

Zie het even als zeer kort door de bocht:
Wat vind je van product X? En oh ja, ik vind het dat product slecht/goed om deze redenen.
Dus dring je al een mening op en dwing je iemand voor of tegen te zijn. Dat is geen discussie.

Ik vind automation veel breder dan de korte samenvatting die je hier schetst. Automation is in mijn ogen niet het automatiseren van repeterend werk. Het is het uitvoeren van handelingen zonder menselijke interactie in mijn ogen. Afhankelijk van een omgeving kunnen handelingen volledig voorgedefineerd zijn, en starten door middel van bepaalde triggers.

Een kamerthermostaat die op een bepaald tijdstip iets gaat doen is een vorm van (home)automation. Een SCOM server die een snmp trap verstuurd bij een bepaald event en als gevolg hiervan een script start is een vorm van procesautomatisering.

De impact is verschillend per persoon en afhankelijk van je huidige functie. Voor mij als "architect" zit hier een uitdaging, voor iemand op een servicedesk kan het een risico zijn.

Automation is natuurlijk meer dan alleen maar alleen maar het centraal aftrappen van taken op server zonder interactie. Maar wat jij doet is een open deur intrappen. Zoals je al gelezen hebt doel ik zeker niet op home automation e.d. Vandaar ook de expliciete verwijzingen waar ik wel op doel.

Nu jij

Over welke impact het heeft op 'mijn organisatie', kan ik niets over zeggen. Ik werk in de detachering en kan vanuit een beperkt perspectief bekijken in hoeverre het impact heeft.

Maar ik zie het als volgt:

Automation vind ik een mes waarmee je uit moet kijken hoe je het gebruikt.

Ja, het is handig en het zorgt voor een verhoogde efficientie. En je kan door die efficientieslag meer werk verzetten met minder mensen. En het is juist met dat laatste waar ik moeite mee heb, voor de overduidelijke reden: Het kost uiteindelijk banen. En natuurlijk moeten de modules onderhouden worden maar dat is uiteindelijk is dat geen 'full-time' job, als het uiteindelijk volwassen code is.

Verder zorgt het ervoor dat de 'ouderwetste' taken wat normaal gesproken door een systeembeheerder, applicatiebeheerder, etc zou doen, verdwijnt. Door automation wordt het werkgebied abstracter en complexer omdat je het niet meer over een enkele server hebt maar over omgevingen praat, op die paar uitzonderingen na.

Even kort door de bocht.

[Meekoh]

Hoe denk ik over Automation?
Het is essentieel als je op een wat grotere schaal gaat werken.
Zoals in mijn sig te lezen is, maak ik (private/hybrid/partner) cloud omgevingen.
Zodra je op die schaal gaat werken, ontkom je niet aan automation. Je wilt dan niet meer met de hand iets doen. Daarnaast wordt veel van het echte beheerwerk uitgevoerd in low-budget landen (lees India), ookal is die Indier nog zo goedkoop hij gaat fouten maken. Een script/runbook kan ook fouten bevatten, maar als je die eenmaal goed werkend hebt kan hij hem foutloos 10.000 keer herhalen.

Veel van de omgevingen waar ik mee werk draaien op Windows Azure Pack en gebruiken dus Service Management Automation (SMA). SMA is onderdeel van System Center Orchestrator en die zal uiteindelijk ook orchestrator gaan vervangen. Alles daarin is gebaseerd op Powershell Workflows.
Dus eigenlijk ben ik voornamelijk aan het automaten met powershell.

[Killah_Priest]

Hoe je automatiseert zal ook nog te maken hebben met de omgevingen welke je moet ondersteunen.
Mijn werkgever bedient voornamelijk MKB klanten waarbij men erg op de centen let : SCCM oid komt er gewoon niet in bij deze klanten.

Het automatiseren van repetetief werk is in mijn geval voornamelijk dmv Powershell bepaalde standaard zaken bij klanten welke veel gedaan moeten worden scripten en schedulen (zeg maar een "poor man's solution"). Denk hierbij aan zaken als users automatisch uit alle AD groepen gooien en uit de GAL halen wanneer je het AD account disabled en in een aparte OU gooit, permissies op Public Folders in Exchange automatisch corrigeren etc.

Niet zo heel spannend dus maar het neemt je wel weer veel onnodig (en ook foutgevoelig) werk uit handen - hoe vaak komt het wel niet voor bij het "handmatig" offboarden van een useraccount dat men vergeet om de user uit de GAL te halen en in ieder geval alle distributiegroepen te verwijderen (ivm bouncemeldingen) ?

[Widow]

Verwijderd schreef op maandag 23 maart 2015 @ 13:12:
[...]
Ja, het is handig en het zorgt voor een verhoogde efficientie. En je kan door die efficientieslag meer werk verzetten met minder mensen. En het is juist met dat laatste waar ik moeite mee heb, voor de overduidelijke reden: Het kost uiteindelijk banen. En natuurlijk moeten de modules onderhouden worden maar dat is uiteindelijk is dat geen 'full-time' job, als het uiteindelijk volwassen code is.

Verder zorgt het ervoor dat de 'ouderwetste' taken wat normaal gesproken door een systeembeheerder, applicatiebeheerder, etc zou doen, verdwijnt. Door automation wordt het werkgebied abstracter en complexer omdat je het niet meer over een enkele server hebt maar over omgevingen praat, op die paar uitzonderingen na.

Even kort door de bocht.

Over het tweede gedeelte: dan ga je er vanuit dat alles geautomatiseerd kan worden. Je bent altijd afhankelijk van een leverancier, als ze geen SDK of API leveren waarmee je tegen een bepaald product kan praten, word het lastig om te automatiseren. En het is ook afhankelijk van datgene wat je automatiseert, als het gaat om een proces dat veranderlijk is, ga je geen tijd winnen met automatiseren, omdat je dan de hele tijd de geautomatiseerde oplossing aan moet passen aan het proces. En als laatste hangt het ook af van de te behalen tijdwinst - voor 10 users aanmaken ga ik geen moeite doen om een script te bakken, die klop ik wel ff handmatig in...

En over de eerste alinea, het kost geen banen, maar het werkgebied verschuift. Vroeger had je mensen die in een fabriek potjes met bonen vulde, labeltjes erop plakte, en de potjes in dozen deed. Ergens in 1950 kwamen er machines om dat te doen, en was er opeens behoefte aan mensen die de apparaten konden onderhouden. Het werk ging dus van fysieke arbeid richting denkwerk, want als een machine niet meer werkte, wat was er mis, en hoe konden ze dat oplossen? En enkele decennia eerder had je de omslag van paard en wagens naar auto's - ineens hoefde men geen paarden of wagens meer, maar was er behoefte aan tankstations en garages. Automatisering is niet nieuw en het gebeurt al eeuwen lang.

En in hedendaagse IT is dat net zo. Niemand logt in op 100 servers om te kijken hoe de performance counters draaien en wat er voorbij komt in de eventlogs. Daar is een SCOM server voor neergezet, en je hebt een SCOM applicatiebeheerder en wat mensen die naar de meldingen kijken die uit SCOM komen. Ja, het werk word abstracter, maar als je het goed doet ook efficienter, en dat is een trend die al jaren aan de gang is in de IT. Ik denk zelf dat de uitdaging met name zit in het efficient automatiseren. Je gaat dingen automatiseren, en vandaag de dag is de techniek volwassen en stabiel genoeg om goed te functioneren. Maar hoe richt je je achterliggende processen in, en hoe train je je mensen om er mee om te gaan? Automatiseren is meer dan alleen een brok techniek ergens naar binnen gooien

[CMD-Snake]

Powergrim schreef op maandag 23 maart 2015 @ 12:40:
In de toekomst vervalt dat ook, dan hebben er RES Workspace manager. De enige image die we dan nog gebruiken is die van een thin client, en die heeft zijn eigen imaging tools.

Ik werk met RES Workspace manager en die kan niet uit zichzelf applicaties distribueren. Daarvoor is nog altijd een aparte distributie tool nodig. RES integreert met die tool om zo de applicaties aan de juiste gebruiker te ontsluiten. Verder kan je ook met de Workspace manager bepaalde settings meegeven of aanpassen voor een applicatie op basis van AD groepen. Dit komt voort uit het oudere Powerfuse.

Automatisering is inderdaad meer dan repeterende taken automatiseren. Het is hele workflows automatiseren. De SCOM servers is een goed voorbeeld. Je kan bijvoorbeeld het zo doen dat SCOM een ticket aanmaakt in het helpdesk systeem. Orchestrator kan alle SCOM meldingen monitoren en voor bepaalde zaken een runbook hebben. Bijvoorbeeld als schijfruimte op dreigt te raken dat de harde schijf automatisch vergroot wordt. Na het uitvoeren van de actie kan Orchestrator de SCOM melding afsluiten en wordt de ticket gesloten.

Je kan ook bepaalde taken uit handen geven. Stel iemand heeft een account nodig in de Active Directory. HR kan dan via een self service portal alle gegevens invullen van die persoon. Orchestrator kan dan op basis van een runbook met die gegevens een AD account maken voor iemand. HR kan dus zelf accounts aan laten maken, maar ze hoeven geen kennis of rechten te hebben om dit te doen.

Zelfde kan ook bijvoorbeeld met een nieuwe virtuele server. Via een self service portal kan iemand een server aanvragen, en na goedkeuring wordt deze automatisch uitgerold. Met System Center Virtual Machine Manager kan dat. Je kan dan ook limieten plaatsen. Iemand kan bijvoorbeeld dan nooit meer dan 4Gb geheugen aanvragen. Maar je kan ook als regel doen dat iemand nooit meer dan 2 actieve VM's tegelijk mag hebben.

Het voordeel is dan ook dat je menselijke fouten kan ondervangen. Als een runbook 1 keer werkt, dan werkt het 1000 keer goed.

[Powergrim]

CMD-Snake schreef op maandag 23 maart 2015 @ 15:06:
[...]
Ik werk met RES Workspace manager en die kan niet uit zichzelf applicaties distribueren. Daarvoor is nog altijd een aparte distributie tool nodig.

En daar is nou net RES AM voor. De applicaties kan je uitrollen met AM, de workspace beheer je met WM. De machines die we gebruiken zijn dan gewoon domme terminals, daar hebben we geen apparte images meer voor nodig. Met een Citrix server er tussen ben je van alle images af, en je applicatie distributie gaat via RES AM.

[Razwer]

Het is leuk deze discussie te lezen hoor, daar niet van, maar automation is compleet afhankelijk van de omgeving en behoeften van de business.
Daarnaast zijn er meerdere wegen die naar rome leiden.

Soms is er ook een ijverige beheerder die vanalles op zijn manier automatiseerd, zonder enige vorm van documentantie en volgens zijn eigen inzichten. Dit kan problematisch zijn bij verloop van medewerkers en aanpassingen in bestaande software.

Het belangrijkste aspect naar mijn mening is het juist documenteren en implementeren van oplossingen. Keuzes maken hier in is het belangrijkste en niet zo zeer de technische oplossingen zelf.
Iedereen die een tijdje mee draait als beheerder weet dat er hedendagen iets "heilig" wordt verklaard, het over 2-3 jaar gedateerd is.

[Verwijderd]

Widow schreef op maandag 23 maart 2015 @ 14:59:
[...]

Over het tweede gedeelte: dan ga je er vanuit dat alles geautomatiseerd kan worden. Je bent altijd afhankelijk van een leverancier, als ze geen SDK of API leveren waarmee je tegen een bepaald product kan praten, word het lastig om te automatiseren. En het is ook afhankelijk van datgene wat je automatiseert, als het gaat om een proces dat veranderlijk is, ga je geen tijd winnen met automatiseren, omdat je dan de hele tijd de geautomatiseerde oplossing aan moet passen aan het proces. En als laatste hangt het ook af van de te behalen tijdwinst - voor 10 users aanmaken ga ik geen moeite doen om een script te bakken, die klop ik wel ff handmatig in...

Wat ook kan. Er zijn pakketten die van A tot Z, dus van ontwerp tot aan daadwerkelijk kunnen bouwen naar jouw specificaties/wensen. Ik behandel nu even het gebied wat voor beheerders geldt maar in feite kan een aanzienlijk stuk naar schatting binnen een jaar of 10 in serieuze staat van geautomatiseerd zijn.
Dus ook de zogenaamd devops, wat een mengelmoes is van ontwikkeling en systeembeheer, zou dan eigenlijk ook binnen een termijn alweer niet meer relevant kunnen zijn.

En over de eerste alinea, het kost geen banen, maar het werkgebied verschuift. Vroeger had je mensen die in een fabriek potjes met bonen vulde, labeltjes erop plakte, en de potjes in dozen deed. Ergens in 1950 kwamen er machines om dat te doen, en was er opeens behoefte aan mensen die de apparaten konden onderhouden. Het werk ging dus van fysieke arbeid richting denkwerk, want als een machine niet meer werkte, wat was er mis, en hoe konden ze dat oplossen? En enkele decennia eerder had je de omslag van paard en wagens naar auto's - ineens hoefde men geen paarden of wagens meer, maar was er behoefte aan tankstations en garages. Automatisering is niet nieuw en het gebeurt al eeuwen lang.

Die automatiseringsslag na de jaren 60/70 was nog oke ommdat er nog daadwerkelijk nuttig werkgelegenheid te creeeren viel. Dat is in dit geval toch echt anders. Waar jij het over hebt is het laagopgeleid werk wat inderdaad erg makkelijk te automatiseren viel. We hebben het nu over pakketten die bij zeer effectief en efficient gebruik een halve afdeling kan weg vagen omdat het werk gewoon verdwijnt. Je hebt met die pakketten die ik in mijn openingspost noemde geen afdelingen meer nodig van 20 man omdat het installeren en het configureren nog met het handje gedaan werd. Nu heb je de mogelijkheden om een klant zijn eigen server in te laten richten met 1 druk op de knop, inclusief de eigenschappen ervan. En echt troubleshooten hoeft ook niet meer want als het echt niet meer kan dan spoel je de boel weer in, zet de backup terug en niemand kijkt er meer naar. En die paar keer dat je echt moet rennen is omdat er weer eens iets veranderd is zonder dat je het doorhad of iets dergelijks.

Ja, het werk word abstracter, maar als je het goed doet ook efficienter, en dat is een trend die al jaren aan de gang is in de IT. Ik denk zelf dat de uitdaging met name zit in het efficient automatiseren. Je gaat dingen automatiseren, en vandaag de dag is de techniek volwassen en stabiel genoeg om goed te functioneren. Maar hoe richt je je achterliggende processen in, en hoe train je je mensen om er mee om te gaan? Automatiseren is meer dan alleen een brok techniek ergens naar binnen gooien

Ik ben het met je eens dat automatiseren niet iets is om zomaar naar binnen te halen onder het mom van "Zo, en nu worden wij efficient". Overigens moet de beweegredenen ook legitiem zijn om automation te kunnen rechtvaardigen. En juist op dit punt zie dat het niet of onjuist gebeurd. En ik heb al voorbeelden gezien waarbij je als personeel gewoon het nakijken bij hebt. Dus imo moet er niet te lichtzinnig nagedacht worden over automation.

[Widow]

Verwijderd schreef op maandag 23 maart 2015 @ 16:27:
[...]
Ik ben het met je eens dat automatiseren niet iets is om zomaar naar binnen te halen onder het mom van "Zo, en nu worden wij efficient". Overigens moet de beweegredenen ook legitiem zijn om automation te kunnen rechtvaardigen. En juist op dit punt zie dat het niet of onjuist gebeurd. En ik heb al voorbeelden gezien waarbij je als personeel gewoon het nakijken bij hebt. Dus imo moet er niet te lichtzinnig nagedacht worden over automation.

Ik begrijp je redenatie, maar vaak is een kostenbesparing al reden genoeg voor een handtekening onder een automatiseringsproject bij een klant. Als de klant hun producten weer goedkoper kan aanbieden dan de concurrentie omdat ze 20 man op straat kunnen zetten, zullen er genoeg bedrijven zijn die dat doen, zodat het bedrijf zelf overeind blijft... de eindklant zoekt de goedkoopste oplossing, daar doe je weinig aan. Dus zullen bedrijven altijd op zoek blijven naar manieren om kosten te besparen. Want als jij het niet doet, doet een ander het wel.

Ik heb in het verleden bepaalde projecten gedaan waardoor een klant niet meer gebruik hoefde te maken van diensten van een bepaalde leverancier. Als je dan later hoort dat dat een eenmanszaak was, en dat de klant die weggegaan is hun grootste klant was en het een behoorlijke aderlating is voor die leverancier... aan de ene kant is het zielig, aan de andere kant merk je met dat soort dingen dat als je als leverancier niet meegaat met de vernieuwingen binnen de IT je binnen no-time je klanten kwijt bent. En dan merk je dat IT gewoon een branche is waar de vernieuwingen af en toe niet bij te houden zijn.

Om het on-topic af te sluiten, iemand zei ooit "Automatiseer, of word geautomatiseerd" en dat is heel erg van toepassing op dit hele verhaal

[janwillemCA]

Los dat automation het beheer van je omgeving efficiënter kan laten verlopen, maakt het je als beheerder ook breder inzetbaar in de zin van het zelf kunnen schrijven van bijvoorbeeld Python en Shell scripts. Iets wat vooral in de open source / linux wereld wel heel handig kan zijn, en je als systeembeheerder zeker waardevoller kan maken.

[Bl@ckbird]

Zelf ben ik wat meer bekent met het Cisco wereldje. Een tijdje geleden viel me op dat Cisco nadenk om hun trainingen te veranderen. CCIE is het hoogst haalbare, maar over een tijdje is dat niet meer genoeg. De netwerkbeheerder moet vooral handig worden met Python. ( Google heeft een aardig bootcamp online staan, die elke new-hire moet volgen.)



Vorige week heb ik een demo gehad van APIC-EM. (Een soort SDN controller voor Cisco routers en switches.) Er werd een Jabber of Lync call gestart en on-the-fly werden de juiste QoS settings geïnjecteerd in de betrokken routers. Was de call voorbij, dan werden deze settings dynamisch weer uit de standaard configuratie gehaald.

Bij firewalls zorgt automation voor verbeterde veiligheid. ACL's / Firewall rules worden vaak te pas en te onpas aan de configuratie van een firewall toegevoegd. Worden applicaties niet meer gebruikt, dan worden deze rules om verkeer toe te staan zelden verwijdert; Men is te bang dat men iets sloopt, waardoor een applicatie niet meer werkt.

Natuurlijk heeft dit invloed op de organisatie, want hoe moet een Change Manager wijzigingen bijhouden, als configuraties dynamisch worden? Standaard commandline werkt ook niet meer; je moet tegen een API babbelen om de juiste debugging informatie uit het systeem te halen.

Steeds meer producten zie ik verschijnen met een API. Was het vroeger alleen CallManager om integraties te bouwen met CRM software, tegenwoordig ook de complete datacenter stack. (VMware, MS Azure Pack, Openstack, Cisco UCS, NetApp storage, Cisco APIC / datacenter netwerk, etc.) Uiteraard om hiermee cloud services / Infrastructure-as-a-Service te bouwen.

Dit zie ik nu ook richting security gebeuren. Met Lancope kan je via netflow abnormaal netwerkverkeer binnen in je netwerk detecteren. (Zoals botnets, medewerkers die interne data downloaden, etc.) Met IPS kan wormen en andere malware detecteren. Met ISE kan je op basis van context van een user, deze user in een bepaald VLAN plaatsen, waar hij toegang heeft tot bepaalde resources. Als deze zaken hebben een API en kunnen met elkaar informatie uitwisselen. Binnenkort wordt het mogelijk dat als een user besmet is met malware en onderdeel is van een botnet, dat detecteren Lancope en de IPS dit. Ze melden dit aan ISE en ISE zorgt dat de user in een appart quarantine VLAN wordt geplaatst.

Verder worden netwerkaanvallen in een bepaalde context geplaatst: Malware voor een Windows PC is irritant, maar niet gevaarlijk als deze aanval op een iOS apparaat gericht was. Beheerders hoefen niet eindeloze syslog messages door te werken en kunnen zich richten op aanvallen die e echt toe doen.

Widow schreef op maandag 23 maart 2015 @ 14:59:
[...]

En over de eerste alinea, het kost geen banen, maar het werkgebied verschuift. Vroeger had je mensen die in een fabriek potjes met bonen vulde, labeltjes erop plakte, en de potjes in dozen deed. Ergens in 1950 kwamen er machines om dat te doen, en was er opeens behoefte aan mensen die de apparaten konden onderhouden. Het werk ging dus van fysieke arbeid richting denkwerk, want als een machine niet meer werkte, wat was er mis, en hoe konden ze dat oplossen? En enkele decennia eerder had je de omslag van paard en wagens naar auto's - ineens hoefde men geen paarden of wagens meer, maar was er behoefte aan tankstations en garages. Automatisering is niet nieuw en het gebeurt al eeuwen lang.

Voor éénmalige acties heeft het geen zin om het te automatiseren. We leven in een kapitalistische wereld en als men geld kan besparen en een actie is repetitief, dat zal het geautomatiseerd worden. De industriële revolutie heeft ons de lopende band gebracht. Hiermee hebben we onze fysieke capaciteiten verbeterd, zoals uithoudingsvermogen, fysieke kracht, etc. De volgende revolutie zorgt ervoor dat we onze hersencapaciteit verbeteren: Denk dan aan machine learning, big data analyse, etc. Dit gaat werkloosheid opleveren, omdat de wet van Moore hiervoor zorgt. Compute power verdubbeld elke twee jaar. Dit is een kwadratisch verband en niet te vergelijken met het rustige tempo van de industriële revolutie. Uber zet nu de taxi wereld op z'n kop. Straks wordt Uber gecombineerd met de zelf-rijdende auto en heb je geen chauffeurs meer nodig.

Deze werkloosheid zien we nu al bij bijvoorbeeld PostNL. Iedereen gebruikt email en post wat wel verstuurd wordt, wordt automatisch gesorteerd. De financiële wereld verliest ook een hoop banen. (Geld is elektronisch en kan elektronisch verwerkt worden.)

Hoog betaalde banen en veel laag betaalde banen zullen blijven bestaan. Het integreren van IT systemen bijvoorbeeld, of sportmasseurs of kapsters. Menselijke interactie is bij deze laatste twee beroepen belangrijk. De Tegenlicht-aflevering van afgelopen zondag ging hierover.

[downtime]

Verwijderd schreef op maandag 23 maart 2015 @ 16:27:
Je hebt met die pakketten die ik in mijn openingspost noemde geen afdelingen meer nodig van 20 man omdat het installeren en het configureren nog met het handje gedaan werd.

Ik weet niet waar jij gewerkt hebt maar installeren en configureren werd al jaren voor een groot deel gescript. Het enige wat echt veranderd is dat automatiseren makkelijker is gemaakt voor mensen die niet kunnen (of willen) programmeren.

En echt troubleshooten hoeft ook niet meer want als het echt niet meer kan dan spoel je de boel weer in, zet de backup terug en niemand kijkt er meer naar. En die paar keer dat je echt moet rennen is omdat er weer eens iets veranderd is zonder dat je het doorhad of iets dergelijks.

Gek genoeg zie ik in de praktijk, in een omgeving met 1000+ Windows bakken, vrijwel geen problemen die met "opnieuw inspoelen" en/of een restore op te lossen zijn. De realiteit is wat complexer dan dat.
Problemen die met "opnieuw inspoelen" te verhelpen zijn waren veelal al te voorkomen door eindgebruikers geen administrators op hun werkplek te maken. Sinds ik geen werkplekbeheer meer doe, zie ik die problemen ook niet meer.

[Verwijderd]

downtime schreef op dinsdag 24 maart 2015 @ 02:16:
Ik weet niet waar jij gewerkt hebt maar installeren en configureren werd al jaren voor een groot deel gescript. Het enige wat echt veranderd is dat automatiseren makkelijker is gemaakt voor mensen die niet kunnen (of willen) programmeren.

Varierend van MKB tot aan bedrijven van enterprise grootte. En ja, ook bij die grote bedrijven werden nog steeds machines ingespoeld en geconfigureerd met het handje. Believe it or not.

Gek genoeg zie ik in de praktijk, in een omgeving met 1000+ Windows bakken, vrijwel geen problemen die met "opnieuw inspoelen" en/of een restore op te lossen zijn. De realiteit is wat complexer dan dat.
Problemen die met "opnieuw inspoelen" te verhelpen zijn waren veelal al te voorkomen door eindgebruikers geen administrators op hun werkplek te maken. Sinds ik geen werkplekbeheer meer doe, zie ik die problemen ook niet meer.

Ik kan niet spreken over Windows want daar ligt mijn expertise niet. Maar onder Unix/Linux/Applicatiebeheer werkt een restore niet zomaar. Afhankelijk van de aanwezigheid van een goede backup is het natuurlijk mogelijk maar daar blijft het dan ook bij.

[ Voor 3% gewijzigd door Verwijderd op 24-03-2015 10:02 ]

[CMD-Snake]

downtime schreef op dinsdag 24 maart 2015 @ 02:16:
Gek genoeg zie ik in de praktijk, in een omgeving met 1000+ Windows bakken, vrijwel geen problemen die met "opnieuw inspoelen" en/of een restore op te lossen zijn. De realiteit is wat complexer dan dat.
Problemen die met "opnieuw inspoelen" te verhelpen zijn waren veelal al te voorkomen door eindgebruikers geen administrators op hun werkplek te maken.

Hoeveel tijd wil je steken in een probleem met een desktop ergens in een bedrijf? Zeker als die desktop niet anders is dan zijn 10.000 mede desktops?

Bij problemen met een werkplek wordt die vaak opnieuw geïnstalleerd omdat het sneller is dan gaan zitten trouble shooten. Noem het ook maar een deel gemakzucht. Maar ik ga me niet meer 8 uur lang bezig houden met een kapotte desktop.

Verwijderd schreef op dinsdag 24 maart 2015 @ 10:02:
Varierend van MKB tot aan bedrijven van enterprise grootte. En ja, ook bij die grote bedrijven werden nog steeds machines ingespoeld en geconfigureerd met het handje. Believe it or not.

Dat een server nog handmatig wordt ingericht snap ik wel. Geen enkele applicatieserver is hetzelfde. De applicatie installeren is slechts een klein deel van het werk, vooral het configureren is de kunst.

Werkplekken worden in Enterprise omgevingen automatisch geïnstalleerd, tenzij het afwijkende werkplekken zijn. Denk bijvoorbeeld aan zaken als speciale randapparatuur of andere bijzondere hardware of software die aanwezig is.

[CAPSLOCK2000]

Wat is het verschil tussen "automation" en "automatiseren"? Het "efficient automatiseren van repeterend werk" is toch al 50 jaar lang de kern van de hele IT-sector? We worden er steeds beter in en steeds meer kan geautomatiseerd worden. Wat precies "automatisch" is veranderd met de jaren ook. De tools die jij noemt zou ik "Configuration Management" noemen. Dat is tegenwoordig een belangrijk deel van het automatiseren en iets dat ik iedereen kan aanbevelen, hoe klein je ook bent. Het maakt je niet alleen efficienter maar ook betrouwbaarder.
Over het verlies van banen maak ik me niet zo'n zorgen. Volgens mij groeit de behoefte aan IT nog altijd en ik ken geen IT-afdeling die genoeg tijd heeft om alles te doen wat ze zouden willen doen. Alle tijd die vrij komt door automatisering kan nuttig besteed worden aan andere taken.

[Verwijderd]

CMD-Snake schreef op dinsdag 24 maart 2015 @ 17:25:
Dat een server nog handmatig wordt ingericht snap ik wel. Geen enkele applicatieserver is hetzelfde. De applicatie installeren is slechts een klein deel van het werk, vooral het configureren is de kunst.

Werkplekken worden in Enterprise omgevingen automatisch geïnstalleerd, tenzij het afwijkende werkplekken zijn. Denk bijvoorbeeld aan zaken als speciale randapparatuur of andere bijzondere hardware of software die aanwezig is.

Oh, dat begrijp ik ook wel. Maar dat soort werk verdwijnt dus ook steeds meer omdat je voor veel zaken standaard waardes en paden aan kan houden.

[Razwer]

Mjah dat kleeft weer aan een andere discussie, "de cloud" en de integratie daar van. Kijk naar een toolset als intune, Azure, etc.

[downtime]

CMD-Snake schreef op dinsdag 24 maart 2015 @ 17:25:
Hoeveel tijd wil je steken in een probleem met een desktop ergens in een bedrijf? Zeker als die desktop niet anders is dan zijn 10.000 mede desktops?

Ik weet niet waar je nou precies op reageert. Ik zei dat ik in mijn werk maar zelden problemen zie die met een herinstallatie op te lossen zijn. Als ik mijn servers vanwege storingen laat herinstalleren dan zullen er niet veel problemen meer opgelost worden, omdat applicatieve storingen nu eenmaal zelden op dat niveau zitten.

Bij problemen met een werkplek wordt die vaak opnieuw geïnstalleerd omdat het sneller is dan gaan zitten trouble shooten. Noem het ook maar een deel gemakzucht. Maar ik ga me niet meer 8 uur lang bezig houden met een kapotte desktop.

Uit de jaren dat ik werkplekondersteuning deed weet ik nog dat je dat van geval tot geval beoordeeld. In een unieke bak met allerlei custom software erop steek je gewoon wat meer tijd dan in een doorsnee werkplek. En als je een probleem vaker terug ziet komen kan het lonen om er wat dieper in te duiken zodat je niet elke keer een herinstallatie hoeft te doen. Want die herinstallatie duurt toch een uurtje en komt altijd ongelegen voor de gebruiker - zeker als je veel mobiele gebruikers hebt die voor zo'n herinstallatie speciaal naar kantoor moeten komen. Dus als je een oplossing vindt die de helpdesk ook kan uitvoeren dan helpt dat iedereen verder.

[Widow]

Maar ook dat hangt af van in hoeverre je je omgeving inricht om te kunnen automatiseren. Ik deed vroeger ook werkplekbeheer, en ik had de standaard applicaties in een image verwerkt, speciale apps werden aangeboden via RDS of App-V, en de gebruikersaccounts waren zo ingericht dat niets lokaal opgeslagen kon worden. Oftewel, zo min mogelijk custom dingen, en zoveel mogelijk standaardisatie. Op het moment dat iemand dan langskomt met een probleem kan je gewoon opnieuw inspoelen, en dat kostte mij nog geen 10 minuten tijd. Het inspoelen zelf duurde een uur, maar dat kan lekker op de achtergrond gebeuren. En wat hierboven al word gezegd, het is voor een deel visie op hoe je je omgeving in kan richten voor automatisering, en voor een deel configuratiebeheer.