Information Technology

To tylko awaria, nic się nie stało

Awarie aplikacji to norma, są nie do uniknięcia. Producenci oprogramowania (niestety) już nas do tego przyzwyczaili.

Nowoczesne oprogramowanie nie stało się mniej zawodne, nawet w miarę upływu czasu i postępu.
Wytwarza się je pod presją czasu. To powoduje niską jakością kodu. Coraz większe tempo wytwarzania oprogramowania nie rokuje by jakość aplikacji miała się poprawić.

Błędy i awarie oprogramowania nieustannie się powtarzają, należy je więc uwzględnić przy budowaniu i eksploatowaniu systemów informatycznych.

Dobrze by było, by jedynym skutkiem awarii aplikacji byłoby prawidłowe, bezproblemowe odtworzenie jej po awarii. Niczym posiadanie przez wspinacza liny asekuracyjnej. Lepiej być przygotowanym na to, że się odpadnie od ściany.

Awaria oczywiście jest niepożądana. Skoro i tak się pojawi, można zaprojektować aplikację tak, by nie zaskoczyła. Awaryjność oprogramowania uwzględnia koncepcja ROC – Recovery Oriented Computing.

Nie jest jeszcze powszechnie stosowana, ale informatyka wykształciła na dzień dzisiejszy wiele mechanizmów obronnych przed zawodnością i awaryjnością:

  • failovery,
  • klastry,
  • loadbalancery, mechanizmy współdzielenia obciążenia,
  • transakcyjne bazy danych,
  • systemy backupowe, itd
  • procedury disaster recovery,

ROC to nie technologia, a zaprojektowana właściwość oprogramowania: w przypadku awarii – zatrzymanie w trybie awaryjnym, a następnie przywrócenie do działania procesem odtworzeniowym po awarii. Ma to sens, ponieważ jeśli oprogramowanie może ulec awarii, należy to w aplikacji przewidzieć i odpowiednio obsłużyć.

Obecnie aplikacje są tworzone bardziej pod kontem wydajności, szybkości przetwarzania (np. z danymi przechowywanymi w RAM). Wiadome jest, że awaria zdarzy się prędzej czy później. Może spowodować katastrofę. Odpowiedzą która minimalizuje skutki błędu aplikacji, jest wprowadzenie rejestracji stanu w pliku dziennika lub bazie danych. Zapisywanie stanów musi odbywać się oczywiście na bieżąco. Pozwala to zachować spójność danych i szybkie odtworzenie po awarii do normalnego stanu – poprawnego działania.

Stan komponentu, modułu czy obiektu jest na bieżąco zapisany. Nie będzie wtedy problemu jeśli nastąpi awaria. Aplikacja zostanie wyłączona, włączona i bez problemu odtworzona do stanu prawidłowej pracy.

Koncepcja ROC zakłada podzielenie aplikacji na niezależne części (komponenty, moduły, obiekty) które niezależnie od siebie pracują, mogą ulegać awarii po których są odtwarzane. Zakłada się tylko dwa stany aplikacji:

  • prawidłowej pracy
  • awarii.

Taka koncepcją interesują się największe firmy informatyczne jak Microsoft czy IBM. W sieci można pobrać przykłady implementacji.