Recommended
More Related Content
Featured
Featured (20)
Life on the ops side - PHP Limburg April 2016
- 1. Life on the ops side Yet Another Default Keynote Template Presentation
- 4. Wat is ops?
- 5. Great minds think different
- 6. Is ops nog nodig?
- 7. Devops!
- 9. Iedereen kan op ieder moment doodvallen
- 10. Layers
- 11. Ops in real life
- 12. Service criteria
- 13. ’t is kapot
- 14. Logging
- 15. Monitoring
- 16. Alerting
- 18. Secret stuff
- 19. Deployments
- 20. Build pipeline
- 21. It works on my machine!
- 22. Waarom gebruiken we X niet?
- 23. Schaal
- 24. Security
- 25. Database-toegang
- 26. Layers (2)
- 28. Nabeschouwingen
Editor's Notes
- - eerst PHP developer, sinds 2007, bij Lithium. Fluoline was onze hoster (met Fluo-kabouters, Music for Life) - dan wat freelance werk, onder andere bij de NMBS - eventjes bij Anaxis - dan Python developer bij Mobile Vikings (toen kende ik nog geen git!) - dan operations, omdat ze aan mij het minste verloren - en omdat ik ’s middags met de rest ging eten - dan drie jaar operations gedaan bij Mobile Vikings - in 2014 “ops fatigue” gekregen - dezelfde problemen bleven maar terugkomen, ik kreeg niet gedaan wat ik wou - in 2015 naar Thanksys gegaan (ik wist dat ik 1) geen operations meer wou doen en 2) niet voor CityLife wou werken) - Nu daar ops-engineer voor een Java app, hoe old skool kan je zijn - En toch modern, Spring Boot, microservices, docker docker docker! - in 2016 begonnen bij Level27, full circle dus - nu bij Thanksys op zoek naar een tweede persoon, om dan misschien andere dingen te gaan doen Mijn dag: RADIUS certificates voor Windows 10, kapotte MacBook upgrade, worstelen met Puppet modules, security audit
- - vroeger de sysadmins - niet enkel de verticale stapeling, maar ook de horizontale - security - configuration management - build engineering - high availability - disaster recovery - second line support - monitoring - on call
- Developers zijn altijd (te) optimistisch (daarom dat je testers nodig hebt) Operations is altijd (te) pessimistisch, zien altijd alles mis gaan -> dit lange termijn is gevaarlijk, bij anderen en bij mezelf gezien. Een burn-out of een bore-out: I don’t care anymore, als het uitvalt is dat pech, ik ben weg. Belangrijk om hier over te praten. Wat is er zo tof aan operations? Toch altijd de shit over ons krijgen? Nooit opvallend wat je doet, enkel als het misgaat (in tegenstelling tot bijvoorbeeld marketing) -> firefighter effect, maar ook gevaarlijk, dat je geen pyromaan wordt! (bedrijf dat enkel bonus geeft als er die maand geen incidenten zijn geweest) - je kan de spil zijn van het bedrijf, je ziet alles (helpdesk, development, anderen) -> maar ook gevaarlijk dat je niet overbelast raakt
- Gaat AWS niet alle sysadmins overbodig maken? - Neen, wat een heel deel van de horizontale eigenschappen blijven relevant Zijn designers nog nodig? Ik kan met Twitter Bootstrap toch ook mooie interfaces maken? - Ze zijn meer nodig dan ooit, doen meer dan enkel posters-voor-het-web ontwerpen, zijn nu user experience engineers. En je ziet dat ze ook richting development gaan, door ontwerpen in JS af te leveren. De scheiding developer/UX’er verschuift, onder andere door opkomst van API-based dinges - En wie heeft er geen schrik van front-enders die er niets van kennen en laag op laag op laag van JavaScript-code bij elkaar flansen?
- Maar je ziet natuurlijk wel een verschuiving: devops - Modewoord! - Uitgevonden door een Gentenaar, zes jaar geleden - Veel aanhang in de ex-sysadmin-wereld, minder in de developer wereld? Omdat ze niet graag on call zijn? - Devops is bipolair?
- Flexibeler mogelijkheden, maar ook grotere schaal Eigen hardware zal blijven bestaan - de wereld is groter dan wat wij kennen alleen! Maar kan wel met dezelfde flexibiliteit beheerd worden (OpenStack bv.), onder andere omdat developers dit gewend zijn (Verhaal Cegeka: nieuwe server klaarmaken kan nu op 10 minuten ipv 2 dagen, maar dan nog 2 dagen wachten op netwerk-team. Dus gaan ze zelf OpenStack gebruiken, om het netwerk zelf in beheer te nemen) Eigen hardware is nuttig, want het blijven abstracties: uiteindelijk draait het wel op een CPU die ergens staat, worden bits opgeslagen op schijven die ergens staan, gaat het verkeer over fysieke kabels En dan zie je dat elke hogerliggende abstractie capaciteiten wegneemt Dikwijls is dat niet erg, omdat onze applicaties niet het uiterste van de hardware vragen (wij zijn errug scheutig met onze hardware, een gemiddelde webpagina vandaag is net over 2 MiB, daar paste destijds Doom in) Maar als je er tegen loopt... Bv. Amazon EBS performance, of guarantees wanneer iets effectief weggeschreven wordt Geen negatieve reclame, maar gewoon iets wat je moet weten, en waar je voor moet plannen.
- En alles kan ook altijd misgaan, op elk moment. Je bent nooit van iets zeker. Los van de software kan je hardware op elk moment falen, kan een netwerklink uitvallen, kan een menselijke fout iets in de war sturen. Daarop belangrijkste focus: uptime Maar hoe belangrijk is uptime echt? Hangt van de klant af Als je Amazon bent: heel belangrijk - alhoewel, Bol.com deed twee jaar geleden ook een release om de maand waarbij alles een paar uur stillag. Als je de bakker om de hoek bent: goh. Maar wat met al die klanten tussenin, die superservice verwachten maar een miniem budget hebben? “De koning komt niet langs vandaag. En zelfs als hij komt…" Leven met onzekerheid over stabiliteit Is eigenlijk hetzelfde als agile, leven met onzekerheid over requirements? Als je weet dat de onderliggende laag niet stabiel is, en je je daar op voorbereidt, dan kom je veel verder. Maar het kost extra moeite Operationele moeite 😃 Embrace failure Embrace change Want de change komt door gaps tussen wensen en realiteit, en is dat geen failure? (Of hetzelfde positiever bekeken)
- elke laag verbergt complexiteit van de vorige laag En da’s goed in een hele hoop gevallen Maar soms wil je die complexiteit wel gebruiken - bv. websockets, webrtc, ... - Puppet libraries voor Apache bv. En dan moet je toch kennis hebben van die onderliggende laag, anders maak je fouten Leaky abstractions
- • Required for? • Maintained by? • Install procedure • (Security) update procedure? • Access control • High availability • Health check • Backup steps and schedule
- Gemakkelijkste situatie: compleet kapot Relatief gemakkelijk: het werkt heel goed Moeilijkste: “het werkt niet” “cannot reproduce" Hoe gemakkelijk kunnen we nagaan of je site nog werkt? Heb je ergens een health check pagina, of een overzicht van het aantal relevante transacties over de afgelopen tijd?
- Voor bugs zijn stack traces en logs nodig Wie heeft automatische bug-reporting? Wie doet er consequent iets mee? Niet gemakkelijk om goed te loggen Fouten kunnen het gevolg zijn van een samenloop van omstandigheden, een stacktrace vangt dit niet altijd Maar zorg tenminste dat je ze al vangt. Kan ook front-end. Idealiter stuur je die logging naar een centrale machine, waar iedereen er aan kan. Als je met ephemeral machines werkt, dan zal je niet anders kunnen. Maar gewone logfiles op de server zelf zijn ook al goed. Enfin, als je aan logrotate denkt! Tools: ELK, Logentries, Splunk, ...
- Traagheid: goed meten. Maar ook doelen bepalen! Performance budget? Eerst de 5 grootste pijnpunten aanpakken (De rol van een goede (project) manager: uit de oneindige lijst de 5 belangrijkste punten halen) Heel handig als je als developer zelf extra meetpunten kan aanmaken -> de devops cirkel is rond! Tools: Graphite, Librato, ...
- Getting up at three o'clock Warnings vs errors Alerts: enkel voor actionable events Aan alerts die je mag negeren heb je niets, die leiden enkel tot moeheid. Wie heeft er een automatische mailfilter voor elke error-mail? Bedenkt dus bij elke error message goed wat er in moet staan: alle context, en what to do next (mag uiteraard ook in de documentatie - ha!) Als je in de uitleg kan zetten wat er moet gebeuren om het op te lossen, had je het dan niet kunnen oplossen in de code? Misschien wel, maar dat is een kwestie van afwegen wat nuttig is, voor jouw budget. Nobody is perfect. This is where the rubber meets the road: pas als je als developer mee on-call bent en alerts beantwoordt, ben je een echte vent/devops.
- Zorgen dat de juiste software op de juiste plaats staat Wat is “de juiste software”? Heb je dat ergens aangegeven? Composer? Maar ook databases, en eventuele speciale configuraties (MySQL collations, Postgres extensies, …) Als ze zeggen “we hebben een server nodig”, dan bedoelen ze “een server met PHP, MySQL en PHPMyAdmin" Zie hier: standaardisatie maakt het eenvoudig, maar soms ook moeilijk. “Beveiliging via .htaccess" Omdat een server op elk moment kan falen, willen we dit ook automatiseren Is niet altijd eenvoudig! Veel geprul soms om dingen te beheren Fail early: smoke tests die we in het begin kunnen uitvoeren Een dependency kan dan te lang blijven staan, maar dat is minder erg dan dat ze er niet staat
- Bv. API keys Niet in de source code! Als ze er in staat, dan koffiekoeken meebrengen! In sommige omgevingen mogen developers niet aan de productie-data. Dat is moeilijk, maar wel een interessante oefening. Sowieso, iedereen die met shared accounts werkt: slechte punten!
- Automatisch en atomair Geen manuele acties Kunnen terugdraaien? Database-migraties zijn altijd kak, zeker als je lang-lopende processen hebt Facebook etc. doet dat mooi, en gradual migrations Maar wij zijn Facebook niet Etsy doet dat met migration Tuesdays
- Zelfs al is het niet nodig, toch handig om te hebben Want het is nodig: wie voert de deployment uit? Wie houdt daar logs van bij? De eerste stap toevoegen is de moeilijkste, daarna gaat het gemakkelijk. (Maar natuurlijk wel zien dat je build pipeline geen single point of failure wordt) Stappen overslaan wil je niet. Verhaal van ops-sollicitant, die hotfix meteen van dev naar productie moest brengen. En daar zat nog een DROP DATABASE in. Leuk! Daarna wel zijn procedures er door gekregen. Als het ergens pijn doen, of te lang duurt, dan moet je dat probleem aanpakken. Amazon, Google, GitHub, Netflix, … releasen inderdaad duizenden keren per dag, maar die hebben een hele batterij automatische testen. Dat is een investering, en je moet je bedrijf effectief overtuigd krijgen om dat geld er in te steken, maar uiteindelijk haal je het er uit. Want je systeem gaat altijd langer mee dan je gedacht/gehoopt had! Daarom dat je procedures wilt hebben. Collega die altijd foeterde op procedures. “Maar wat ik wel mis, is een afspraak wanneer iets naar productie kan." (Ik haat ook procedures hoor. En checklists. Maar ik weet dat ze nodig zijn. Hoe meer je er mee bezig bent, hoe gemakkelijker het wordt.)
- Ik mag het verdorie hopen ja! Verschillen tussen lokale omgevingen en productie kunnen belangrijk zijn - wel of niet asynchrone taken - simultane requests - dingen nog niet gecommit in de database! - meerdere webservers? - waar plaatsen we bestanden? - sessies - locking - voorbeeld van abstractie-lekken die naar boven komen Andere dingen op dezelfde host - delays - conflicteren requirements van libraries
- Omdat we Y gebruiken! Eén developer kan meer tools bedenken dan een ops team van tien in de lucht kan houden Tools vertellen je waar ze goed in (claimen) te zijn, maar niet wat ze niet goed kunnen Er is altijd een kost bij het gebruiken van een nieuwe tool, zelfs al is ze as a service Jij verandert toch ook niet elke maand van underlying framework, of van programmeertaal? Je hebt in elk project een aantal technologie-tokens. Doe niet te veel vernieuwing tegelijkertijd. Vernieuw vooral op je business, daar waar je waarde toevoegt. Overengineering: zie de Javascript-wereld. Een simpele hello world in React is errug zwaar. (ook daar: layers!) Als je op je pagina maar drie mouseovers moet hebben, heb je dat niet nodig. Voordeel van oude en saaie technologie: elke fout die je tegenkomt, is iemand anders al eens tegengekomen. (Behalve bij VikingCo, waar ze een fout in MySQL C-code tegenkwamen, en dan via git-bisect de commit zochten. What the fuck?) Gebruikers geven niet om de database die je gebruikt, die geven om de service die je biedt. Wij zien dat verkeerd.
- Wij opereren niet op de schaal van grote bedrijven. Neen, echt niet. http://aadrake.com/command-line-tools-can-be-235x-faster-than-your-hadoop-cluster.html 1,75 GiB schaakspelen 26 minuten in Hadoop, met 7 c1.medium machines 12 seconden met shell scripts http://yourdatafitsinram.com/ Tot 6 TiB kan het nog in RAM Dus dingen die voor hen werken, gaan niet noodzakelijk voor ons werken. Basecamp is een majestic monolith https://m.signalvnoise.com/the-majestic-monolith-29166d022228#.kclxcv6sv Grote kost van alles op te delen Is natuurlijk een moeilijke keuze, waar moet je mikken? Ongeveer iets verder dan waar je denkt uit te komen Je kan later altijd nog optimaliseren Maar denk agile! you ain’t gonna need it! Als je denkt dat het gaat groeien op dimensie X, dan zie je dat het gaat groeien op dimensie Y Twitter is ook niet doodgegaan aan z’n fail whales
- De poort openzetten is het gemakkelijkst - security: open MongoDB instances: https://www.shodan.io/report/nlrw9g59 https://www.shodan.io/search?query=product%3A%22mongodb%22+country%3A%22BE%22 Moeilijker is precies bepalen welke toegang nodig is, en dat onderhouden (services komen en gaan, mensen komen en gaan) Saai, maar misschien interessant te maken door red/blue exercises: ene team valt aan, andere team probeert tegen te houden Zouden we ook voor testing kunnen gebruiken? Maar ook hier: risico’s afwegen, niet iedereen moet even strikt zijn
- Mag ik aan de de database? Wel, eigenlijk niet. De kans dat je iets kapot gaat maken is gewoon te groot. Four eyes principe (pair programming) kan al veel verhelpen. Ah ja, en replicatie is niet hetzelfde als een backup, als je een drop table doet... Let op met database-queries die je main site onderuit helpen! FFS, leer de basis van indexen. Dat was het eerste wat ik deed bij Mobile Vikings. 5 indexen, en de load was 10% ipv 100%
- Kunnen we daar geen Varnish voor zetten? Wel, dat kan je, maar dan moet je wel de juiste headers meegeven. Kleine layout fix met cache-probeersel: iedereen kreeg opeens dezelfde persoonlijke header te zien. Oeps. Los problemen op in de juiste laag Je kan in Varnish veel, je kan in Apache veel, maar je lost het probleem het best op waar het zich voordoet. Anders ga je het later vergeten, en werken dingen opeens niet meer zoals ze moeten.
- Gaan ze alles oplossen? Ik ben scepticus. Altijd geweest. Of conservatief. Of angstig. Containers op zich bestaan al lang. Docker verpakt ze erg mooi. Maar je ziet ook dat bij elke versie er nieuwe features zijn waarvan je dacht “ah dju ja, die had ik al langer nodig!" Containers kunnen ook gevaarlijk zijn, als je ze gewoon als black boxes bekijkt. Wat als je openssl moet updaten op al je machines? Maar veel dingen die je verplicht bent te doen met containers, gaan ons dwingen best practices (die al langer bestonden) af te dwingen. Zoals we nu ook niet meer gewoon bestanden aanpassen via Dreamweaver en FTP, maar via git werken. Maar the greatest thing since sliced bread? Ik denk het niet. Remember the layers, remember the scale. Er komt altijd wel iets anders