Ana içeriğe atla

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

Bir Uluslararası Yazılım Şirketinin Batış Hikayesi

 Güzel başlamıştı hikaye. Yazılımcılar mutlu, kullanıcılar memnundu. Sonra pandemi başladı. Sorun para değildi. Olmayan şey huzurdu… Durdurun hype trenini, inecek var kırık kalpler durağında  — Photo by Kelly Sikkema on  Unsplash Gerçek olamayacak kadar güzeldi çalışma ortamı. Yazılımcılara istedikleri eğitim ve donanım alınıyordu, personel arası hiyerarşik bir yapı yoktu, sorumluluğun yanında yetki de veriliyordu, esnek çalışma saatleri yazılımcılara göre esnekti, izin isteyen hiç kimse geri çevrilmiyordu, pandemiden önce bile uzaktan çalışma vardı. Ne oldu bu şirkete? Nazar mı değdi? Şirketin yazılım ürünü Türkiye’de doğmuştu. Ürün birçok ülkede hem kamu tarafından hem de özel sektör tarafından kullanılıyordu. Yazılım geliştirme ekipleri hem Türkiye’de hem de diğer ülkelerde bulunuyordu. Yazılımın argesi için gelen geri bildirimlerin çoğu Türkiye’den geliyordu. Yazılımın kalbi Türkiye’de atıyordu.  Koronavirüs pandemisi nedeniyle Türkiye’de kamu kuruluşları hizmet alımı ile aldıklar

Türkiye'de Yazılım Şirketi Açmak ve Çıldırmamak

Aklında bir fikir vardı. Piyasada bunu karşılayan yazılımlar vardı ama hepsi eksikti. Hayalindeki yazılım ürününe hiçbiri yaklaşamıyordu. Gördüğü kadarıyla piyasanın böyle bir ürüne ihtiyacı vardı. Kullanıcılar mevcut ürünlerden şikayetçiydi. Kendi ekibini toplayıp hayalindeki şirketi kurmaya niyetlendi. Rüzgarlara dikkat!- Francesco Ungaro -  Pexels İşinden istifa etmeden önce piyasa araştırmasını yaptı, rakip ürünleri inceledi. En önemlisi ekibini kurdu. Ürününün MVP hali için çalışmaları başlattı. Girişim kurmak ile ilgili birçok kitap ve blog okudu, podcastler dinledi. Girişimci birkaç kişinin çayını kahvesini içti. Öngörebildiği her şey için önlemini aldı ve istifa edip kendi yazılım şirketini kurdu. Şirket kurmak için gerekli süreçler düşündüğünden daha kolay geçti. Şirketin adı ve logosu zaten hazırdı. Şirket teknoparkta yerini almıştı. Kendisi etiketlere çok önem vermiyordu ama yine de LinkedIn’deki profiline “Founder of the …” ibaresini ekledi. MVP’nin ortaya çıkması hedefini

Yazılımcılar İçin Yan Proje Oluşturma Rehberi

İster hobi amaçlı olsun ister maddi amaçlı her yazılımcının bir yan projesi olmalıdır. Peki yan proje oluştururken nelere dikkat edilmelidir, nasıl bir yan projemiz olmalıdır? Organize olalım beyler Yan proje (side project) için öncelikle bir fikir bulmak gerekli. Bu projenin amacı ne olacak? Hangi ihtiyacı çözecek? Yeni bir fikir mi olacak yoksa mevcut bir fikrin daha iyi uygulanmış bir hali mi olacak? Sadece yeni bir teknolojiyi öğrenmek için mi? Deneysel mi olacak ya da eğlenceli mi? Yoksa maddi bir getirisi olacak mı? Bu proje ürün olursa kimler kullanacak? Ürünü kullanacak kişilere erişip geri bildirim alabilecek miyim? . . . Bu soruların doğru bir cevabı yok, cevaplar size bağlı. Ama proje bir amaca hizmet edip bir ihtiyacı çözecekse, hele birde maddi getirisi olacaksa motivasyonunuz yükselecektir. Bunun yanında sadece eğlence amaçlı olan deneysel bir proje yapmak stressiz bir öğrenme ortamı sağlayacaktır. Gün içinde proje için aklınıza gelen her şeyi not alın. Not almazsan