Güvenilir Yazılım Örneği (COVID19)


Medikal cihazlardan (örneğin ventilatör) veri almaya ve bu cihazları yönetmeye yarayan yazılımlarımız hem Türkiye’deki hem de yurtdışındaki bazı hastanelerde 7x24 olarak kullanıcı kaynaklarında (on premises) çalışmakta. COVID19 salgınına, oluşan yoğunluklara, hastanelerdeki sık personel değişimine, medikal cihazların sürekli çalışmasına, internet trafiğinde ve hastane içinde yer yer oluşan network dar boğazlarına rağmen yazılımlarımız güvenilir(reliable) bir şekilde çalışmayı sürdürüyor.

Veri almak ya da alamamak, işte bütün mesele bu!
Koronavirüs salgını nedeniyle yazılımlarımızın çalışmasında ve destek sağlamada herhangi bir aksaklık olmadı. Medikal IoT cihazlardan oluşan ve kullanıcı kaynaklarında çalışan yazılımımızı nasıl güvenilir yaptık? İşte dikkat ettiğimiz hususlar:

Her zaman en kötüsü için hazırlık yapın. Öngöremeyeceğiniz senaryoların daima var olduğunu kabul edin. Yazılımınızın yapması gereken işi yapabilmesi en iyi senaryodur. Bunun dışında kalan senaryolar daima vardır. Biz hastanede kullanılan medikal kemik matkabından kaynaklanan elektromanyetik etkileşim nedeniyle kablosuz iletişimin yavaşladığını ve koptuğunu bir dedektif gibi araştırarak ancak bulabildik. İletişimin kopabileceğini en baştan göz önüne aldığımız için bu durum sistemin işleyişini kesmedi, sadece yavaşlattı. Network durumunu sürekli izlediğimiz için sorundan hemen haberimiz oldu.

Otomatik düzeltme mekanizmaları olsun. Sisteminizde bir hata oluştuğunda bu hatanın zincirleme olarak başka hatalara neden olmaması için otomatik devre kesme (circuit breaker) mekanizmaları olsun. Bunlar mümkün değilse yazılımlarınız size haber versinler. Eğer bir sistemden belirli bir süre haber alamıyorsanız alarmlar çalsın. Incident management (IcM) teşkilatınız ve sisteminiz hazır olsun.

Otomasyonla yapılabilecek her şeyi otomasyon ile yapın. Hasta bilgisi girişini cihazlar arası haberleşme ile otomatik hale getirerek bile birçok hatayı engelledik. Ayrıca salgın hastalık ortamında kullanıcı etkileşimini azaltarak hastalık bulaşma riskini de azaltmış olduk.

Kullanıcıları iyi yönlendirin. Şöyle kullanıcılar olabilir: yazılımın kullanımı ile ilgili eğitim almamış, kullanım kılavuzunu okumamış, kötü niyetli, kestirme yol bulmaya çalışan, acelesi olan, yorgun olan, yetkin olmayan sistem yöneticileri, yanlış yönlendiren sistemciler, biz bir şey yapmadık sizin sistem gitti diyenler... Kullanıcılara anlamlı bilgilendirme ve hata mesajları gösterin. Talimatları uzun metinler halinde göstermeyin, adım adım gösterin. Kâğıda basılı kılavuzlar hiçbir cihazın çalışmadığı senaryolarda (internetin çekmediği ve steril olmayan cihazların alınmadığı ameliyathane) hâlâ kullanılıyor.

Dürüst ve açık hata mesajları verin. “Bir hata var bize ulaşın” yerine “hata şundan kaynaklanmaktadır, şu adımları takip edin, hata tekrar oluşursa şuradan bize ulaşın” gibi bir mesaj gösterin. Bu esnada hata sizin izleme sisteminize düşmüş olsun, siz kullanıcıdan önce davranarak hatayı giderin, size telefon ya da eposta geldiğinde kullanıcıya zaten bu hata üzerinde çalıştığınızı belirtin. Hata sizden kaynaklı ise bunu açıkça belirtin.

Ölçün ölçebildiğiniz her şeyi, izleyin izleyebildiğiniz tüm metrikleri. Sistemleriniz size durumlarını periyodik olarak bildirsin. Durumunu bildirmeyen sistem varsa alarmlar çalsın. Sisteminiz ne kadar yoğun kullanılıyor, ilerleyen zamanlarda sisteminize ne kadar yük binecek, işlem ve depolama kapasitesi ne kadar artırılmalı, %90’lık bir işlemci kullanımı hangi durumlarda olabilir, versiyonlar arası kaynak kullanımında ne kadar fark var, kullanıcı alışkanlıkları ne yönde, hata loglarında anormallik var mı … bu gibi soruların cevabını bilmeniz gerekiyor.

Yedeklemeyi her alanda düşünün. Donanımsal yedekler, yedek internet çıkışı, firewall’da yanlışlıkla(!) yasaklanan portlar nedeniyle yedek portlar, kâğıt kullanıcı kılavuzları, acil müdahale ekibi (incident response team) yedek kişiler.

Sistemler aynı ölçü birimlerinde konuşsun. Değil dakika, saniye farkı olan sistemler birbirinin işleyişini bozabiliyor. Eğer gerçek zamana yakın verilerle uğraşıyorsanız zaman farkı, ölçüm hassasiyet farkı, metin kodlama (encoding) farkı gibi hususları ortak bir birime dönüştürmek emeğinizin büyük kısmına talip olabilir. Ama sağlıklı çalışan bir sistem için bunu yapmak zorundasınız.

Yazılımınız için testleriniz olsun. Unit test ve integration test olduğu gibi stres testleriniz de olsun. Kullanıcı kaynaklarında çalışacak yazılımınız varsa bir de “sistemciler” testi yapın. “Sistemciler” yazılımınızın kullandığı portu yasaklayabilir, sanal makinenizin ağ çıkışını salyangoz hızına düşürebilir, SSL sertifikalarınızı bir tıkla tehlikeliymiş gibi gösterebilir, canları sıkıldıkça sanal makinenizi yeniden başlatabilirler. Sistemcilere selam olsun.

Versiyonlamayı düzgün yapın. Özellikle kullanıcı kaynaklarında çalışacak (on premises) yazılımlarınız varsa bu yazılımların eski kalacağını, güncellemelerinin yapılmayacağını varsayın. Farklı versiyonlarda yazılım mümkün olduğunca aynı davransın, mümkün olduğunca hatayı çözme adımları aynı olsun.

Güncelleme sisteminizi iyi yapılandırın. Eski kalan bir yazılımınız güncelleme çekmek istediğinde güncelleme işlemi için elverişli olup olmadığını, ona hangi sürümdeki hangi dosyaları ileteceğinizi, güncelleme ters giderse işlemleri nasıl geri alacağını otomatik olarak belirleyen bir güncelleme sistemi geliştirin. Siz yorulmayın, bırakın sistemler kendi aralarında işi halletsinler.

Yeniden başlatmak düşmanınız olsun. Bir bilgisayarı yeniden başlatınca neler olabilir ki demeyin. Kullanıcıların kendi sistemlerine yüklediği başka bir yazılım, işletim sistemi güncellemesi, sabitlenmemiş IP adresi, otomatik başlayan uygulamaların getirdiği sistem yükü, sisteme eklenmiş yeni bir sistem politikasının aktif olması gibi senaryolar yüzünden eskiden çalışan yazılımınız eskisi gibi çalışmayabilir.

Ölçeklenebilir kodlarınız ve sisteminiz olsun. Yazılımınıza ne kadar yük geleceği konusundaki tahmininiz bir kenarda dursun. Kullanıcınızdan bir telefon alıp, yazılım kapasitesini bir gecede çalışan sistemleri etkilemeden artırmanız gerekebilir.

Hata giderme dokümanları çok zaman kazandırıyor. Hatayı ilk karşılayan teknik destek personeli firmanızı temsil ediyor. Onun elini güçlü tutmak, kullanıcı karşında utandırmamak gerekiyor. Kullanıcının bilgilerini telefonu açmadan görebilmelidir, kullanıcıya birkaç tıklama ile doküman ve video gönderebilmeli, oluşan hataya göre kullanıcıya ücretsiz ek hizmetler ve süre tanımlama inisiyatifine sahip olmalıdır.

Güvenli haberleşme kesinlikle olmalı. Yazılımlar arasındaki haberleşme güvenilir olmalı. Bu birçok saldırıyı, yanlış kullanımı, bilgi sızmasını engellediği gibi yüksek erişilebilirliği de artırıyor. Bizim kullandığımız bir port numarasını başka bir firmanın yazılımına girmişler. Güvenli haberleşme için gerekli adımlar sağlanmadığı için (sadece SSL değil, versiyon bilgisi sağlanması, mesaj bütünlüğü doğrulaması gibi) bağlantı sürekli reddedilmişti. Böylece hem kendi sistemimizi hem de diğer firmanın sistemi en baştan itibaren korumuş olduk.

Sorumluluklar kesin olsun. Verinin yedeğinin kim tarafından ne sıklıkla alınacağı, hangi yazılım ve donanımların kim tarafından karşılanacağı, hangi hataya bunun eğitimini almış kullanıcı bakacak hangi hataya siz bakacaksınız, hata gidermede hangi yöntemler kullanılacak (uzak bağlantı ile mi cihaz başına kadar giderek mi)

Test ve dokümantasyon için harcadığımız emeğin salgın günlerinde biz ve sağlık çalışanları için birçok fayda sağlaması bizim için tatlı bir tecrübe oldu.

Yorumlar

Bu blogdaki popüler yayınlar

KPSS Çalışan Yazılımcı

On-Prem Çilesi

Yeteneğini Kaybeden Yazılımcı