Reliability - Güvenilirlik - Belirli Bir Süre Zarfında Kaç Tane Hata Olduğu

Reliability Nedir ?
Türkçesi güvenilirlik. ISTQB'nin Türkçe açıklaması şöyle

Belirli durumlar altında, belirli bir zaman aralığında veya belirli bir sayıda operasyonel iş için yazılımın beklenilen işlevselliklerini yerine getirebilme yeteneği (ISO 9126)

ISTQB'nin İngilizce açıklaması şöyle

Reliability, which is the capability of the software product to maintain a specified level of performance when used under specified conditions.

Bir başka açıklama şöyle

Reliability is usually defined as the probability or frequency of failures, when using a system in a specified environment. If over a period of time T we observe n failures, then our reliability expressed as a frequency is roughly r = n/T.

Bir başka açıklama şöyle

The likelihood of a system to run without failure for a period of time. Systems can be made more reliable by reducing single points of failure, and detecting failures quickly.

Yani sistemin belli sürede ne kadar hata verdiğinin ölçülmesidir.

Beklenmeyen Durumlar
Reliability sanki sadece beklenmeyen durumlarda ölçülür gibi bazı tanımlar da var. Bir tanesi şöyle. Bence bu tanım tam doğru değil çünkü sadece beklenmeyen koşullarda değil her zaman için Reliability ölçümü yapılır.

Risk of software failure and the stability of a program when exposed to unexpected conditions. Reliable software has minimal downtime, good data integrity, and no errors that directly affect users.

Güvenilir (Reliable) Sistem Ne Yapmaz ?

Açıklaması şöyle. Yani hatayı sessizce göz ardı etmez, mümkünse düzeltmeye çalışır

A reliable system does not fail silently or return incorrect results or create corrupted data. A reliable system is architected in a way that puts effort into avoiding failures, and when it’s not possible it will detect, report, and maybe even try to auto-remediate them.

Güvenilirlik (Reliability) Ne Kadar Önemli?

Şöyle bir düşünüş tarzı var. 

Reliance is not a binary state of mind; it's much more subtle than that. Consider that we may rely on the mail carrier to deliver our mail each day, but as the consequence of failure is not catastrophic, we do not rely upon it heavily. OTOH, if you are a diabetic living in a remote location, your reliance on the mail carrier's delivery of your insulin has far greater implications.

Buna göre bir sistemin arıza vermesi ölümcül ise Reliable (Güvenilir) olmalıdır. Ancak değilse o kadar Reliable olması gerek olmayabilir. 

Örnek - Reliability vs Kullanım Kolaylığı

Bu örnekte ise ölümcül bir durum var. ISS uzay istasyonunun Reliable olması için insanların kolayına giden bazı özelliklerden feragat ediliyor. Yani burada Reliability daha önemli, bu yüzden istasyon dönmüyor ve zero-g. 

Any rotating station needs non-rotating components: solar panels need to face the Sun, radiators need to be shadowed, docking points need to be non-moving, and so on. Making a rotating joint that can last decades is hard; if the hub of a rotating station seizes up, the resulting accelerations are likely to tear the station apart and kill everyone aboard.

Making a rotating airtight joint is even harder, and you'll need one if you want both a rotating living space and a non-rotating laboratory.

Örnek - Reliability vs Maliyet

Designing Data Intensive Applications kitabından aldım. Bu örnekte ölümcül bir durum yok.  Bu düşünüş tarzına göre maliyeti azaltmak için Reliability 'den feragat edilebilir

Reliability is not just for nuclear power stations and air traffic control software —more mundane applications are also expected to work reliably. Bugs in business applications cause lost productivity (and legal risks if figures are reported incorrectly), and outages of ecommerce sites can have huge costs in terms of lost revenue and damage to reputation.

Even in “noncritical” applications we have a responsibility to our users. Consider a parent who stores all their pictures and videos of their children in your photo application. How would they feel if that database was suddenly corrupted? Would

they know how to restore it from a backup?

There are situations in which we may choose to sacrifice reliability in order to reduce development cost (e.g., when developing a prototype product for an unproven market) or operational cost (e.g., for a service with a very narrow profit margin)—but we should be very conscious of when we are cutting corners.

Site Reliability Engineering (SRE) Nedir?

Dev miktarda trafiğe sahip Google, Amazon gibi şirketlerde ortaya çıkmış bir kavramdır. Müşterilere sağlanan servislerin, kesintiye/sıkıntıya uğramadan çalışmasını sağlamaya çalışan birimdir. Bu birim sitedeki tüm bileşenler ile ilgilenir. Bu kavram 3 tane değerli şey sunuyor. Bunlar şöyle.

Reliability Engineering Provides Business Value
Reliability Engineering Empowers Development
Reliability Engineering Fosters an Empathetic Culture of Learning

Bu sitelerde SRE'nin karşılaştığı bazı problemler şöyle

- Complex metrics

- Disparate data sources

- Constant updates

- More layers

SRE için kullanılabilecek bazı araçlar burada

ISO 9126 ve ISO/IEC 25010 Quality Characteristics

Reliability başlığı altında şu maddeleri toplamış. Yani reliability ile maturity, fault tolerance, recoverability kelimeleri genellikle iç içe kullanılırlar.  Açıklaması şöyle

Reliability — Degree to which a system performs specified functions under specified conditions for a specified period of time.

a) Maturity — how stable is the app during everyday use?

b) Availability — can the users use the app when they need to?

c) Fault tolerance — can the app work even when there are some hardware or software faults? How long will it take to recover?

d) Recoverability — in the event of an interruption or a failure, can the app recover the data affected directly and re-establish the system?

Example: “In case of a DDOS attack, the system gateway detects and blacklists the attacking IPs preventing the system crash.”

1.Maturity

Açıklaması şöyle

how stable is the app during everyday use?

2. Fault Tolerance

Açıklaması şöyle

can the app work even when there are some hardware or software faults? How long will it take to recover?

Fault Tolerance yazısına bakabilirsiniz. Genellikle Reliability ve Fault Tolerance birbirine karıştırılıyor. Kendi uydurduğum bir örnek şöyle

Diyelim ince bakır tel zımbayı ezecek bir alete ihtiyacım olsun. Bı aletin de çok ama çok reliable olmasını istiyorum. Aletimi çok sağlam bir malzeme olan titanyumdan imal etmeye karar verdim. Böylece günce beş bin zımba telini ezen ve bir milyon sene boyunca hiç arıza çıkartmaya bir sistemim olur. 

Fault Tolerance ise yazılım ve donanımın çok iyi malzeme ve işçilik olmamasından dolayı illaki bir noktada bozulacağını varsayar. Eğer yine aynı aleti yapmak isteseydim ancak elimde sadece tunç olsaydı bu sefer aletimin bir milyon sene çalışacağını garanti edemem. Mecburen bozulacağını varsayıp farklı bir çözüm üretiyorum. Örneğin Redundancy (Yedeklilik) kavramı bu sefer devreye giriyor.

3.Recoverability

Açıklaması şöyle

in the event of an interruption or a failure, can the app recover the data affected directly and re-establish the system?

Örnek

Açıklaması şöyle

Example: “In case of a DDOS attack, the system gateway detects and blacklists the attacking IPs preventing the system crash.”

Örnek

Sanırım şöyle bir örnek verilebilir. Sistemde bir Watchdog/Monitor servisi bulunur ve ölen, tıkanan şeyleri yeniden başlatır, temizler.

4. Reliability compliance
Örnek ver

5. Performans
Performance Efficiency başlığı altına düştüğü gibi Reliability başlığı ile de ilgili. Performans iyileştirmesinden dikkat edilecek en önemli madde şöyle.

"Don't optimize until you know what to optimize"

Yani önce ölçüm yap. Daha sonra iyileştir ve yine ölçüm yap anlamına geliyor.

Reliability ve Flexibility

Sistemin güvenilir olması, her koşulda çalışabilmesi demektir. Güvenilir olmak, kolay özellik ekleme çıkarma yeteneği ile genellikle ters orantılıdır. "Flexibility breeds complexity" cümlesine bu konuya değiniyor.

Reliability Kaybı
Bir sistem güvenilirliğini kaybettiğini tespit ederse failsafe (güvenli aksama) durumuna geçerek bazı işlevlerini durdurabilir. Bir örnek şöyle

How did the first real-time embedded system also produce the first timing bug?

The AGC computer weighed in at 30 kg, ran at 1MHz and only had 74Kb of ROM and 4Kb of RAM.

Despite the somewhat limited performance of the hardware, the AGC real-time operating system was capable of executing up to 8 jobs at a time using cooperative multi-tasking (i.e. each job had to periodically surrender control back to the OS).

The system, both hardware and software, had been extensively tested for years before it would be used. But after just a few hours of being switched on, the system started to issue error messages indicating that a job deadline had been missed. It then rebooted the system … and again … and again. This made the operator of the AGC quite uncomfortable.

Understandably so when you know that 'AGC' stands for 'Apollo Guidance Control' and that, in this case, the operator was Neil Armstrong during the descent of the Apollo 11 landing module.

The errors reported meant the computer was running out of processing capacity (reportedly because Aldrin had decided to leave the docking radar on) and scheduling new radar jobs before the previous ones had finished. The computer finally switched to fail-safe mode (rebooting and chucking away low priority jobs) which saved the mission.

This was 50 years ago and we now have the tools (scheduling, partitioning, WCET, ...) to avoid this kind of problem and many more. But it's always good to have a fail-safe for the ones we don't yet know about … just in case.

Reliability Örnekleri

Bunları iyi örnekler mi bilmiyorum.

- The system must be able to perform its functions for an average of 23 hours 50 mins per day.
- The system must perform adequately for up to 30 users.
- The system must allow 12,000 new customers per year.

Reliability Gereksinimleri Ayrı Yazılmaz İse Ne Olur
Reliability gereksinimleri genellikle sistemin tamamı içindir. Ancak bazen reliability gereksinimi non-functional olarak işaretlenmek ve ayrı bir bölüme yazılmak yerine, functional gereksinimler içine karışıyor. Bu durumda sanki sadece o ilgili alanı ilgilendiriyormuş gibi görünse de aslında çoğu kere sistemi ilgilendiren bir husus oluyor. Eğer zamanında tedbir alınıp bu gereksinimler functional gereksinimlerde ayrılmazsa projenin ileriki aşamalarında müşteri ile çatışmaya sebep oluyor. Sonra ayıkla pirincin taşını :)

Reliability Nasıl Ölçülür?
Reliability non-functional requirement olduğu için bir şekilde ölçülebiliyor olması gerekir.  Reliability şu şekilde ölçülemez!

R = Koşulan Test Sayısı / Crash Sayısı

Testler sistemin beklendiği şekilde işlediğini ispatlar, fakat sistemde hiç hata olmadığını ispatlamaz!

Belki bir günlük performans testi yapılarak belki reliability ölçülebilir.

Mean time Between Failure - MTBF 

MTBF de farklı şekillerde hesaplanabiliyor. Bir soru ve cevap şöyle. Yani Güvenilirlik  MTBF duvar saatine göre değil, uçuş saatine göre hesaplanıyor.

Q : In aircraft reliability monitoring analysis, why the calculation of defect rate is per 1000 FH?

In aircraft reliability monitoring analysis when we calculate the alert level, why the calculation of defect rate is per 1000 FH?

A : When calculating a rate, you have to decide what time unit you use as a basis.

For reliability monitoring, using wall clock time would not make sense, since most defects are caused by use of the aircraft, not degradation of materials over time.

Therefore, flight time is more appropriate than wall clock time. Using a basis of 1 flight hour, would result in very low numbers of defect rate. Multiplying those numbers by 1000 gives a bigger number, easier to work with (fewer 0s behind the decimal separator).

It must be noted that systems do degrade over time, also when they are not flown. Temperature cycles during day and night causing expansion and retraction of materials, humidity causing corrosion and evaporation of oil components in lubricants are some of the mechanisms that will cause defects over time but they are not driven by the number of flight hours.

When the defect rate is expressed in flight hours, some assumptions need to be done on the utilisation rate of the aircraft in order to take these calendar time effects into account. This will result in higher MTBUR/MTBF values for aircraft that fly a lot (e.g. airline use) vs lower values for infrequently used aircraft (e.g. business aircraft).