ݺߣ

ݺߣShare a Scribd company logo

Miért fontos a Chaos Engineering?

•
•
Janos Szendi-Varga
Janos Szendi-Varga

Tudtad, hogy Csernobil is egy Chaos Engineering gyakorlatnak indult? Az elmúlt néhány évben a Chaos Engineering nagyon népszerűvé vált. Már nem csupán a nagy cégek, mint a Netflix és a Google játékszere ez, hanem mindenkinek alkalmaznia kell, aki folyamatos szolgáltatást akar nyújtani ügyfelei számára, és szeretné az üzletmenetét folytonossá és hibatűrővé tenni. Az előadásban bemutatok néhány gyakorlati példát, hogy miként tudjuk alkalmazni ezeket a módszereket, fejleszteni a rendszerünket, és hogy hogyan tudjuk megmenteni a napot, amikor beüt a káosz.

1 of 16
Download to read offline
MIÉRT FONTOS A CHAOS ENGINEERING? SZENDI-VARGA JÁNOS
SZENDI-VARGA JÁNOS ▸ Tanácsadó @ Graph Coding Kft. ▸ Szoftver architekt ▸ Gráf adatbázis tanácsadó ▸ Alapítója a Neo4j Budapest Meetup csoportnak ▸ @szenyo ▸ janos@graphcoding.com 2
MI AZ A CHAOS ENGINEERING?
Miért fontos a Chaos Engineering?
HOGYAN LEHET MAGYARRA LEFORDÍTANI AZT, HOGY CHAOS ENGINEERING?
TÖRTÉNELEM ▸ Jessie Robbins “Master of Disaster” @ Amazon (2001-2006) 
 https://en.wikipedia.org/wiki/Jesse_Robbins ▸ GameDay: a rendelkezésreállás javítása, rendszeres gyakorlással, hibák szándékos előidézésével ▸ Failure Friday at PagerDuty ▸ A nagyvállalatok használták kizárólag kezdetben ▸ Egyre népszerűvé vált: ”Netflix does it and thinks you should too” ▸ 2016: A Chaos Engineering alapjai (Principles of Chaos Engineering)
 http://principlesofchaos.org ▸ 2017: Chaos Engineering könyv az O’Reilly-től (Casey Rosenthal, Lorin Hochstein,, Aaron Blohowiak, Nora Jones,, Ali Basiri)
PÁR JÓ TANÁCS, MIELŐTT ELKEZDJÜK ▸ Megfelelő kultúra (engineering culture) ▸ Menedzsment bevonás ▸ Profi teszt csapat ▸ Hibatűrő rendszer ▸ A produkciós környezetben kísérletezz ▸ Egyszerre egy “experiment” ▸ Nagy piros gomb ▸ Automatizáld a kísérleteket, hogy folyamatosan futtathatók legyenek ▸ Minimalizáld a hatókört ▸ Minden hibatűrőnek hitt komponenst érdemes megtesztelni ▸ Munkaidő utáni futtatás -> nem jó ötlet ▸ Posztmortem
EGY CHAOS GYAKORLAT LÉPÉSEI (PRINCIPLESOFCHAOS.ORG) 1. Kezdjük a "nyugalmi állapot" definiálásával, amikor a rendszer valamilyen mérhető tulajdonságát tekintjük normál működésnek. 2. Feltételezzük, hogy a nyugalmi állapot megmarad mind a kísérleti és a kontroll csoportban. 3. Idézzünk elő olyan eseményeket, amelyek valós eseményeket szimulálnak, mint szerver összeomlás, merevlemez rendellenesség, gyenge hálózati kapcsolat, stb. 4. Próbáljuk cáfolni az eredeti feltételezésünket úgy, hogy megfigyeljük hogy van- e eltérés a nyugalmi állapotban a kontroll és a kísérleti csoport között.
MIVEL KEZDJÜK? ▸ Known Knowns - Amivel tisztában vagyunk, és értjük is ▸ Known Unknowns - Dolgok, amivel tisztában vagyunk, de nem teljesen értjük ▸ Unknown Knowns - Amit értünk, csak nem tudunk róla ▸ Unknown Unknowns - Ezeket nem ismerjük, és nem is értjük
TIPIKUS TÉVHITEK, VÁROSI LEGENDÁK ▸ A hálózat megbízható ▸ Zéró késleltetés ▸ A sávszél végtelen ▸ A hálózat biztonságos ▸ A topológia nem változik ▸ Egy rendszergazda van ▸ A transzport költség nulla ▸ A cert-ek nem járnak le ▸ A hálózat homogén ▸ A szoftver hibamentes ▸ Van mentésünk ▸ stb.
Miért fontos a Chaos Engineering?
▸ Egy egész adatközpont, vagy régió kiesésének szimulálása ▸ Törölni néhány Kafka topic-ot, különböző instance-eken ▸ DNS elérhetetlen ▸ Késleltetés injektálása a forgalom egy részére, amikor a szolgáltatások egymást hívják ▸ Funkcionális hibák okozása ▸ Kód inzertálás: Beinjektálása a célprogramba, és bizonyos utasítások előtt hiba előidézése ▸ Időutazás: A szerverek rendszeridejét különbözőképpen állítjuk be ▸ I/O hibák szimulálása ▸ Kimaxolni a CPUt néhány cluster tagon
 ÖTLETEK, TIPPEK, HOGY MILYEN HIBÁKAT SZIMULÁLJUNK “A HIBÁT JOBB ELŐIDÉZNI, MINT ELKÖVETNI.”
ESZKÖZÖK, AMIKET HASZNÁLNI LEHET ▸ Chaos Monkey (https://github.com/Netflix/chaosmonkey) ▸ Mangle (https://vmware.github.io/mangle/) ▸ https://github.com/asatarin/testing-distributed-systems ▸ https://github.com/dastergon/awesome-chaos-engineering ▸ Chaos Toolkit (https://github.com/chaostoolkit/chaostoolkit/ ) ▸ Chaos Blade https://github.com/chaosblade-io/chaosblade ▸ CM4SB https://github.com/codecentric/chaos-monkey-spring-boot ▸ Latency Assault ▸ Exception Assault ▸ AppKiller Assault ▸ Memory Assault ▸ Visualise your Chaos Engineering Experiments with Grafana https://www.youtube.com/watch?v=Gua-QcdoivU ▸ Planning your first experiment https://medium.com/@adhorn/chaos-engineering-ab0cc9fbd12a
CM4SB ▸ POST  http://127.0.0.1:8080/actuator/chaosmonkey/enable ▸ POST  http://127.0.0.1:8080/actuator/chaosmonkey/disable ▸ POST  http://127.0.0.1:8080/actuator/chaosmonkey/assaults
 {
 "level": 1,
 "latencyRangeStart": 100,
 "latencyRangeEnd": 600,
 "latencyActive": true,
 "exceptionsActive": false,
 "killApplicationActive": false,
 "restartApplicationActive": false
 }
ÉRDEKESSÉGEK ▸ “Egy nemzetközi repülőtér működése során elengedhetetlen rendszeresen tesztelni azoknak a készültségét, akik egy előre nem látható légi esemény esetén a kényszerhelyzet kezelésében részt vennének.”
 https://www.bud.hu/budapest_airport/media/hirek/aktualis_sajtokozlemenyek/ repulogep_katasztrofat_szimulaltak_a_ferihegyi_repuloteren.html ▸ Szürke szamár a ködből: SRE-szakember a semmiből:
 „Öt évvel ezelőtt még nem volt site reliability engineer (SRE), de az elmúlt évben több ilyen jellegű megbízásunk is akadt, ami nem teljesen DevOps, és nem is teljesen fejlesztés, hanem a kettőnek a köztese” - Farkas Tamás, Grafton
 https://itbusiness.hu/technology/aktualis_lapszam/highway/forintok-fele-mutato- magnestu-az-informatikusok-fizetesi-korkepehez
KÖSZÖNÖM A FIGYELMET! ▸ @szenyo (Twitter) ▸ janos@graphcoding.com

More Related Content

Miért fontos a Chaos Engineering?

  • 1. MIÉRT FONTOS A CHAOS ENGINEERING? SZENDI-VARGA JÁNOS
  • 2. SZENDI-VARGA JÁNOS ▸ Tanácsadó @ Graph Coding Kft. ▸ Szoftver architekt ▸ Gráf adatbázis tanácsadó ▸ Alapítója a Neo4j Budapest Meetup csoportnak ▸ @szenyo ▸ janos@graphcoding.com 2
  • 3. MI AZ A CHAOS ENGINEERING?
  • 5. HOGYAN LEHET MAGYARRA LEFORDÍTANI AZT, HOGY CHAOS ENGINEERING?
  • 6. TÖRTÉNELEM ▸ Jessie Robbins “Master of Disaster” @ Amazon (2001-2006) 
 https://en.wikipedia.org/wiki/Jesse_Robbins ▸ GameDay: a rendelkezésreállás javítása, rendszeres gyakorlással, hibák szándékos előidézésével ▸ Failure Friday at PagerDuty ▸ A nagyvállalatok használták kizárólag kezdetben ▸ Egyre népszerűvé vált: ”Netflix does it and thinks you should too” ▸ 2016: A Chaos Engineering alapjai (Principles of Chaos Engineering)
 http://principlesofchaos.org ▸ 2017: Chaos Engineering könyv az O’Reilly-től (Casey Rosenthal, Lorin Hochstein,, Aaron Blohowiak, Nora Jones,, Ali Basiri)
  • 7. PÁR JÓ TANÁCS, MIELŐTT ELKEZDJÜK ▸ Megfelelő kultúra (engineering culture) ▸ Menedzsment bevonás ▸ Profi teszt csapat ▸ Hibatűrő rendszer ▸ A produkciós környezetben kísérletezz ▸ Egyszerre egy “experiment” ▸ Nagy piros gomb ▸ Automatizáld a kísérleteket, hogy folyamatosan futtathatók legyenek ▸ Minimalizáld a hatókört ▸ Minden hibatűrőnek hitt komponenst érdemes megtesztelni ▸ Munkaidő utáni futtatás -> nem jó ötlet ▸ Posztmortem
  • 8. EGY CHAOS GYAKORLAT LÉPÉSEI (PRINCIPLESOFCHAOS.ORG) 1. Kezdjük a "nyugalmi állapot" definiálásával, amikor a rendszer valamilyen mérhető tulajdonságát tekintjük normál működésnek. 2. Feltételezzük, hogy a nyugalmi állapot megmarad mind a kísérleti és a kontroll csoportban. 3. Idézzünk elő olyan eseményeket, amelyek valós eseményeket szimulálnak, mint szerver összeomlás, merevlemez rendellenesség, gyenge hálózati kapcsolat, stb. 4. Próbáljuk cáfolni az eredeti feltételezésünket úgy, hogy megfigyeljük hogy van- e eltérés a nyugalmi állapotban a kontroll és a kísérleti csoport között.
  • 9. MIVEL KEZDJÜK? ▸ Known Knowns - Amivel tisztában vagyunk, és értjük is ▸ Known Unknowns - Dolgok, amivel tisztában vagyunk, de nem teljesen értjük ▸ Unknown Knowns - Amit értünk, csak nem tudunk róla ▸ Unknown Unknowns - Ezeket nem ismerjük, és nem is értjük
  • 10. TIPIKUS TÉVHITEK, VÁROSI LEGENDÁK ▸ A hálózat megbízható ▸ Zéró késleltetés ▸ A sávszél végtelen ▸ A hálózat biztonságos ▸ A topológia nem változik ▸ Egy rendszergazda van ▸ A transzport költség nulla ▸ A cert-ek nem járnak le ▸ A hálózat homogén ▸ A szoftver hibamentes ▸ Van mentésünk ▸ stb.
  • 12. ▸ Egy egész adatközpont, vagy régió kiesésének szimulálása ▸ Törölni néhány Kafka topic-ot, különböző instance-eken ▸ DNS elérhetetlen ▸ Késleltetés injektálása a forgalom egy részére, amikor a szolgáltatások egymást hívják ▸ Funkcionális hibák okozása ▸ Kód inzertálás: Beinjektálása a célprogramba, és bizonyos utasítások előtt hiba előidézése ▸ Időutazás: A szerverek rendszeridejét különbözőképpen állítjuk be ▸ I/O hibák szimulálása ▸ Kimaxolni a CPUt néhány cluster tagon
 ÖTLETEK, TIPPEK, HOGY MILYEN HIBÁKAT SZIMULÁLJUNK “A HIBÁT JOBB ELŐIDÉZNI, MINT ELKÖVETNI.”
  • 13. ESZKÖZÖK, AMIKET HASZNÁLNI LEHET ▸ Chaos Monkey (https://github.com/Netflix/chaosmonkey) ▸ Mangle (https://vmware.github.io/mangle/) ▸ https://github.com/asatarin/testing-distributed-systems ▸ https://github.com/dastergon/awesome-chaos-engineering ▸ Chaos Toolkit (https://github.com/chaostoolkit/chaostoolkit/ ) ▸ Chaos Blade https://github.com/chaosblade-io/chaosblade ▸ CM4SB https://github.com/codecentric/chaos-monkey-spring-boot ▸ Latency Assault ▸ Exception Assault ▸ AppKiller Assault ▸ Memory Assault ▸ Visualise your Chaos Engineering Experiments with Grafana https://www.youtube.com/watch?v=Gua-QcdoivU ▸ Planning your first experiment https://medium.com/@adhorn/chaos-engineering-ab0cc9fbd12a
  • 14. CM4SB ▸ POST  http://127.0.0.1:8080/actuator/chaosmonkey/enable ▸ POST  http://127.0.0.1:8080/actuator/chaosmonkey/disable ▸ POST  http://127.0.0.1:8080/actuator/chaosmonkey/assaults
 {
 "level": 1,
 "latencyRangeStart": 100,
 "latencyRangeEnd": 600,
 "latencyActive": true,
 "exceptionsActive": false,
 "killApplicationActive": false,
 "restartApplicationActive": false
 }
  • 15. ÉRDEKESSÉGEK ▸ “Egy nemzetközi repülőtér működése során elengedhetetlen rendszeresen tesztelni azoknak a készültségét, akik egy előre nem látható légi esemény esetén a kényszerhelyzet kezelésében részt vennének.”
 https://www.bud.hu/budapest_airport/media/hirek/aktualis_sajtokozlemenyek/ repulogep_katasztrofat_szimulaltak_a_ferihegyi_repuloteren.html ▸ Szürke szamár a ködből: SRE-szakember a semmiből:
 „Öt évvel ezelőtt még nem volt site reliability engineer (SRE), de az elmúlt évben több ilyen jellegű megbízásunk is akadt, ami nem teljesen DevOps, és nem is teljesen fejlesztés, hanem a kettőnek a köztese” - Farkas Tamás, Grafton
 https://itbusiness.hu/technology/aktualis_lapszam/highway/forintok-fele-mutato- magnestu-az-informatikusok-fizetesi-korkepehez
  • 16. KÖSZÖNÖM A FIGYELMET! ▸ @szenyo (Twitter) ▸ janos@graphcoding.com