Witam,

> Bez analizy ryzyka i bez konkretnego poznania co i jak może się popsuć
> niezależnie, udowodnienie czegoś jest ciężkie.

Oczywiscie.

> No i najpierw w ogóle trzeba mieć jakieś dane nt. niezawodności poszczególnych
> komponentów. Z czym bywa różnie. Dla hardware czasem jeszcze coś można dostać,
> dla software -- z rzadka.

No wlasnie. Mam konkretny HW. Domyslnie oni gwarantuja, ze jalowy HW
bedzie dzialal dobrze.
Ale dostawca instaluje OS np. Linux lub Windows. Nie bardzo mam dane,
ale moge przyjac,
ze to bedzie X (OS availability w zaleznosci od HW).

> Poważna trudność to common failure modes -- dla
> software to np. bug w stosie komunikacyjnym powodujący, że jak przyjdzie jakiś
> tam komunikat to stos się wywala. I jeden dobrze rozpropagowany komunikat
> wykłada nam cały sytetm z fafset "niezależnych" komponentów.

Wiem. Wlasnie takie analizy mam - czyli wiadomo co nalezy do SPOF.
Rowniez mam definicje kiedy nasz klient uwaza, ze system lezy nawet
jesli
komunikacja dziala i niektore moduly dzialaja, ale jakas informacja
nie jest dostarczana
i system calosc nie jest sprawna.

> Tak czy siak potrzeba wiele szacować.

Jasne.

> Możemy wtedy napisać że mamy dostępność 9.997. Albo, co tu jest istotne(!) możemy
> napisać że jest np. 9.999 albo po prostu 100% -- a czas niedostępności bierzemy
> na klatę i na kary umowne za niedostępność powyżej dopuszczalnego limitu.

Tak to jest rozwiazanie, ale unikamy takich trikow.

> Pojawiło się całkiem sporo serwisów gwarantujących po prostu dostępność 100% --
> a realny czas niedostępności refundują w ramach gwarancji.

Tak, ale to jest chwyt prawniczy a nie techniczna analiza
zagadnienia :-).

Pozdrawiam,

--
|\/\/| Seweryn Habdank-Wojewódzki
\/\/
Professionalism in programming - www.accu.org