-
Data: 2011-08-08 09:40:24
Temat: Re: Dostepnosc systemu - metody formalne
Od: Sebastian Kaliszewski <s...@r...this.informa.and.that.pl> szukaj wiadomości tego autora
[ pokaż wszystkie nagłówki ]Seweryn Habdank-Wojewódzki wrote:
> 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 :-).
Ale przy szacowaniu typu 4 czy 5 dziewiątek to ja z definicji nie mam zaufania
do "technicznej analizy zagadnienia". Bo jest problem "unknown unknowns". Na
"unknown unknowns" przykładów historycznych mamy (zbyt) wiele. Żebym miał
zaufanie, to mnie któś musi przekonać, że wziął pod uwagę te niewiadome
niewiadome i ma na nie niemal całkowicie pewne (też wielodziewiątkowe)
ograniczenie z góry.
Ot choćby:
1. Space Shuttle. Robiono różne analizy niezawodności i niby wyszło, że szansa
utraty statku wraz z załogą w jednej misji jest rzędu 1:10000 (mamy 4
dziewiątkową niezawodność). Realne dane historyczne wskazują, że tak naprawdę
można mówić o niezawodności rzędu 1:50 -- na 135 misji mamy 2 utraty statku i
załogi i 1 parszywy close-call ("failure mode" praktycznie taki sam jaki
zniszczył Columbię trafił się już wcześniej, i to w 2. misji po utracie
Challengera -- wtedy się udało bo dziura została wybita w szczęśliwym miejscu
gdzie akurat pod spodem był gruby element metalowy, który sprawnie odprowadzał
ciepło dalej, a nie pusta przestrzeń).
2. Albo ostatnio Fukushima -- nie przewidzieli że jednocześnie padną generatory
dizlowskie, zasilanie z sieci i transport kołowy, pozwalający na dowiezienie
akumulatorów z zewnątrz.
3. Albo ostatnio incydent z silnikiem RollsRoyce-a w Airbusie 380... W silniku
pękł dysk turbiny -- takie coś waży setki kg i przy dzisiejszej technologii nie
da się tak zbudować silnika, by taki połamany dysk z niego nie wyleciał na boki
(robi się osłony wytrzymujące łopatki wentylatora, ale na dysk turbiny nie ma
mocnych -- energia głównych fragmentów jest jak pocisku z działa dużego
kalibru). Samoloty się certyfikuje tak, by pojedyncze przestrzelenie przez
pojedynczy znaczny fragment dysku nie "zdejmowało samolotu z nieba". Przyjmuje
się trafienie 1 fragmentem bo taki dysk rozpryskuje się mniej więcej
równomiernie we wszystkich kierunkach (przed rozpryśnieciem jest pi*drzwi w
stanie równowagi, inne elementy są zbyt delikatne by istotnie zmienić tor ruchu)
i zwykle pęka na 3 główne fragmenty (plus nieco mniejszych). Tu wyszło inaczej
-- samolot został trafiony przez 3 istotne framgenty (z czego 2 duże) i tylko
jeden duży poleciał nie trafiając samolotu. Czyli była awaria której
konstruktorzy nie przewidywali -- istotne przewody elektryczne i hydraulika
zostały przecięte w 3 różnych miejscach (przy okazji został przestrzelony jeden
z dźwigarów w skrzydle i zbiornik paliwa). Na szczęście było więcej marginesów
niż przewidywała specyfikacja i certyfikacja i tym razem się udało. Ale parę
osób twierdzi, że samolot innego typu miałby marne szanse.
>
> Pozdrawiam,
pzdr
\SK
--
"Never underestimate the power of human stupidity" -- L. Lang
--
http://www.tajga.org -- (some photos from my travels)
Następne wpisy z tego wątku
- 11.08.11 10:04 Seweryn Habdank-Wojewódzki
- 12.08.11 17:21 R. P.
- 12.08.11 18:18 n...@m...invalid
- 12.08.11 20:55 A.L.
- 12.08.11 21:41 R. P.
- 12.08.11 21:55 p...@p...onet.pl
- 12.08.11 22:18 p...@p...onet.pl
- 12.08.11 22:24 R. P.
- 12.08.11 22:50 p...@p...onet.pl
- 12.08.11 23:07 R. P.
- 13.08.11 18:06 R. P.
- 13.08.11 19:02 slawek
- 13.08.11 19:04 Michoo
- 13.08.11 19:23 R. P.
Najnowsze wątki z tej grupy
- TCL - problem z escape ostatniego \ w nawiasach {}
- Nauka i Praca Programisty C++ w III Rzeczy (pospolitej)
- testy-wyd-sort - Podsumowanie
- Tworzenie Programów Nieuprzywilejowanych Opartych Na Wtyczkach
- Do czego nadaje się QDockWidget z bibl. Qt?
- Bibl. Qt jest sztucznie ograniczona - jest nieprzydatna do celów komercyjnych
- Co sciaga kretynow
- AEiC 2024 - Ada-Europe conference - Deadlines Approaching
- Jakie są dobre zasady programowania programów opartych na wtyczkach?
- sprawdzanie słów kluczowych dot. zła
- Re: W czym sie teraz pisze programy??
- Re: (PDF) Surgical Pathology of Non-neoplastic Gastrointestinal Diseases by Lizhi Zhang
- CfC 28th Ada-Europe Int. Conf. Reliable Software Technologies
- Młodzi programiści i tajna policja
- Ada 2022 Language Reference Manual to be Published by Springer
Najnowsze wątki
- 2024-11-14 Dobra zmiana
- 2024-11-14 Czy prezydent może ułaskawić od zadośćuczynienia? [A. Lepper odszkodowania]
- 2024-11-14 Gliwice => Network Systems Administrator (IT Expert) <=
- 2024-11-14 Gliwice => Administrator Systemów Sieciowych (Ekspert IT) <=
- 2024-11-13 Filtr do pompy ruskiej
- 2024-11-12 Gdzie kosz?
- 2024-11-13 elektrycznie
- 2024-11-12 Jebane kurwa, kurwy.
- 2024-11-13 karta parkingowa
- 2024-11-13 Wl/Wyl (On/Off) bialy/niebieski
- 2024-11-12 I3C
- 2024-11-13 Kraków => DevOps Engineer (Junior or Regular level) <=
- 2024-11-13 Łódź => Senior SAP HANA Developer <=
- 2024-11-13 Zabrze => Senior PHP Symfony Developer <=
- 2024-11-13 Karlino => Konsultant wewnętrzny SAP (FI/CO) <=