Więc oto sprawa dotycząca SLA i SLO: są to *cele.* Zespoły robią wszystko, co w ich mocy, aby je osiągnąć, i historycznie często im się to udaje. Gdy awaria narusza SLO, firma, która je obiecuje, może być zobowiązana do zapłacenia kary umownej. Ale to jest oprogramowanie... nieprzewidziane rzeczy mogą się zdarzyć!
Abhimanyu
Abhimanyu25 paź, 01:48
Jako inżynierowie backendowi często traktujemy AWS DynamoDB/S3 i ich dostępność na poziomie czterech dziewiątek jako pewnik. Jednak 14-godzinna awaria przypomniała nam, że wartości reklamowane ≠ rzeczywistość. Zawsze projektuj zabezpieczenia dla krytycznych systemów!
W końcu chodzi o zarządzanie ryzykiem: 1. Jaką dostępność obiecuje dostawca i na ile możesz mu zaufać? 2. Jak duży wpływ na Twoją firmę miałoby naruszenie SLO? Jaki jest Twój plan B, gdy to się stanie (awaria dostawcy)? Czy w ogóle masz plan B?
Oprogramowanie staje się dość chaotyczne w porównaniu do innych branż, a my musimy być w stanie zarządzać tym chaosem, żyć z nim, okiełznać go i pracować wokół niego. To wszystko dlatego, że oprogramowanie ciągle się zmienia! Szczerze mówiąc, to coś, co sprawia, że inżynieria oprogramowania jest naprawdę wyzwaniem + ekscytującym!!
42,53K