Merhaba canlarım. Bu yazıda bir önsöz ile giriş yaparak vaktinizi almadan direk konuya girmek istiyorum. Şuuraltı boşalmalarım için gerekli olan anlamsız önsöz yazılarımı başka konu başlıklarına bırakıyorum. Aslında bunu demekle de bir girizgah yapmış oldum ama… Herneyse.

2011 senesinde Kütahya il özel idaresinde işe başladım. Kurumun taşra bir kurum olması ve bilgi işlem müdürlüğünün yan bir müdürlük olması sebebiyle o zamanlar herşey -tabiri caizse- ya analog mantıkla işliyordu yada excel gibi günü kurtaracak local çözümler üretilmişti.

Bunun yanında yeni hizmet binasına geçme konusunda bir çalışma vardı. Bunu bir milat kabul ederek a ‘dan z ‘ye bir planlama yapıp uygulamaya koyduk. Tabi herşey plan ile %100 uyumlu gidemiyor maalesef. Bu yazının bir diğer yan amacı uygulama aşamasında karşılaştığımız engelleri anlatmaktır. Çok detay vererek sıkmak istemiyorum. Ana hatlarıyla anlatmaya çalışacağım. Ama şunu söyleyeyim biz çalışmalarımız yaparken çoğunlukla bir ihtiyaç hasıl olmasını beklemedik; bir teknoloji duyduğumuzda, okuduğumuzda onunla alakalı bir arge yapıp sonra bunu nerede kullanabiliriz diye uygulama alanı bulduk.

İlk önce en temelden başladık. Taa gaz ve toz bulutlarından. En temelden alır sağlam uygular ve bir daha geri dönmezsek ivmelenerek başarıya ulaşacağımızı düşünüyorduk. Büyük oranda da yanılmamışız. Bunun yanında bizimki gibi kısıtlı personel sayınız varsa aynı işe tekrar tekrar dönülmemeli ki iş üresin. Yoksa aynı şeylerin etrafında dönüp duruluyor.

Aşamaları başlık başlık incelemeden önce bu yazının ana fikirlerinden biri olarak şunu söyleyeyim: Herşeyi yedekli planlayın. Akıllı switchlere çektiğiniz hatlardan, UPS ‘e kadar.

Sağlam bir ağ altyapısı
Binanın planına bakarak sistem odasının olması gerektiği yeri, fiber ve bakır kabloların nereye kadar geleceğini, omurga switch ve diğer akıllı switchlerin kapasitelerini, vlan kapsamlarını… Bu noktada uzmanlaşmış bir kurumdan tavsiyeler almadan planlama yapılmamalı.

Omurga switch olarak HPXXX kat başlarındanki switchler olarak da HPXXX seçtik. Fiyat performans olarak en başarı o zaman onlardı. (Şuan bir alım yapmamız gerekirse Ruijie ‘yi öneririm) Her kata iki tane switch koymaya karar verdik. Ağı olabildiği kadar fiber kablolarla oluşturduk. İyiki de böyle yapmışız. Bu bizi bugün bu yazıda anlattığımız sunucu odasından kurtulmak konusunda aşırı rahatlatıyor. Kat başındaki switclere kadar fiber kablolar geliyor. Bunun yanında switchlerimiz arasına bakır kablolarla yedek bir hat çektik. Beklenmedik durumlarda bunları kullanıyoruz. Bu sayede ağ bağlantısı en fazla 5 dk kopuyor.

Siber Güvenlik
Ağı tasarlayınca önüne koyacak bir firewall araştırmaya başladık. pfSense ‘yi biraz test ettik, çok stabil bulmadık. İstemci yönetimi bizi 250 kullanıcı loglama ve izinlendirmede biraz yoracak gibi geldi. Sonra o zaman için bize en iyi fiyatı veren Fortinet ‘i denedik. Lisans bedeli ödemesi çok da içimize sinmemesine rağmen personel adama konusunda bizi rahatlatacağını düşündüğümüz için bunu kabul ettik. Ama notlarımızın arasında Ahtapot ürününü test edip fortiyi devre dışı bırakmak var. Zamanla bunu kullanacağız.

Sunucu ve disk havuzu
Kurumda araç takip ve maaş programları gibi çeşitli makineler üzerinde çalışan yada o iş için alınmış sunucular üzerinde sanallaştırılmamış servisler vardı. Hem bunları derlemek hem de yazılım konusundaki hayallerimizi geçekleştirmek için bir sanallaştırma platformuna ihtiyacımız olduğuna karar vermiştik. 4 tane fiziksel sunucumuz vardı.

Daha önceki yazılarımızdan da anlaşılabileceği üzere eğer birşeyin açık kaynak tarafında bir muadili varsa biz onu kullanırız. En azından uğraşırız. Bu anlayışla çeşitli ürünleri test ettik. Hyper-V ve Vmware ilk akla gelenler ama bağımlı olmamak ve lisans ödememek için bunlara çok sıcak bakmadık. KVM ‘yi ve VirtualBox ‘ı inceledik. Ücretli ürünlerle kıyaslanamasa da ihtiyaçlarımızı karşıladığını gördük. En son Proxmox ile tanıştık. Şunu söyleyebilirim Vmware cluster ne ise bu da neredeyse o. Çok az kısıtı var. İnternette kaynaklar olabildiğince geniş. Ve sorularınıza hemen yanıt alabileceğiniz bir forumu da mevcut. 4 sunucumuzdan 3 ünü Proxmox cluster için kullandık. 1 tanesini storage için ayırıyoruz. Bizce küme yapısı olmazsa olmaz. Sunuculardan birinin başına birşey gelse diğer sunucular onun yükünü de paylaşıyor. Bu sayede neredeyse sunucunun kapandığını anlamıyorsunuz bile. Yüksek erişilebilirlik çözümleri çok iyi. Tabi bunun için ortak bir disk kullanmalısınız.

Önce raid yapılarını ve farklı storage standartlarını inceledik. Sunucu disk altyapısı olarak dağıtık bir disk mimarisi kullanmayı uygun bulduk. Bu sayede hem daha hızlı hemde daha güvenli yüksek erişilebilir bir disk havuzumuz olacaktı. Ceph ‘e karar verdik. Bu da yine Vmware dağıtık disk mimarisinin açık kaynak tarafındaki muadili olarak düşünülebilir. Ceph için de üzerine proxmox kurduğumuz sunucuları kullanıyoruz. Bu 3 sunucumuz hem disk havuzumuz hem de bu disk havuzunu kullanan sanallaştırma kümemiz oldu.

Disklerden biri gidiyor diğerleri onu telafi ediyor. Sunuculardan biri gidiyor diğerleri onu telafi ediyor. Neredeyse hiçbir servis durmuyor. İstediğimiz tam olarak da buydu.

Proxmox ve Ceph

Sonra ağdaki tüm servisleri, fiziksel ve sanal makineleri clonezilla ile proxmox üzerinde oluşturduğumuz sana makinelere taşıdık. Bitti mi? Neredeyse. Bu vmleri bağımsız bir storage ‘e yedeklememizin daha doğru olduğuna karar verdik. Daha önceki storage araştırmalarımız da FreeNas gözümüze çarpmıştı. Replikasyon özelliğini ve neredeyse tüm disk standarlarını desteklemesi bu seçimimizde bizi ikna etti. FreeNas ‘ı kullanarak hem vmleri buraya yedekleyeceğiz hem de personelin ihtiyacı olan ortak paylaşımları burada barındıracağız. Böyle de yaptık. Sonra bir tane replikasyon için FreeNas kurduk ve uzak bir lokasyona yerleştirdik. Bunun yüksek kapasiteli bir sunucu olmasına gerek yok. Ana FreeNas storage ‘ımız günün belirli zamanlarından bu uzak FreeNas ‘ı replike ediyor.

FreeNas ve Replikasyon

Monitoring
Ağı ve sunucuları kendimizce çok iyi tasarladık ama bunun izlenmesi gerekli. Beklenmedik bir durum olduğu anda haberimiz olmalı. İstersek geçmişe doğru log taraması yapabilmeliyiz. Burada bir parantez açarak şimdiye kadar bahsetmediğim birşeyden bahsetmek istiyorum. Bu dönüşüme başlamadan önce kendi imkanlarımızla bir low code platform geliştirmeye başlamış, çekirdeğini de bitirmiştik. Bu platform bize kompleks uygulamaları bile çok efor sarfetmeden kısa sürede tasarlamamızı sağlıyor. Bunun yanında neredeyse her standartta ve her servisten okuma ve yazma yapabiliyor. İleride detaylarını vereceğiz. Burada böyle bir izleme yazılımı ihtiyaç olunca 1 hafta gibi kısa bir sürede kendi izleme modülümüzü geliştirdik. Bu modül sayesinde “bir yazıcının kartuşu azalırsa ve stokta yoksa stok görevlisi personele mobil bildirim gönder” yada “Arvento sunucusu kapalı olmasa bile log out olursa sistem yöneticisine mesaj at” gibi senaryoları bile gerçekleyebiliyorduk. Daha sonraki süreçte bu monolit uygulamamızı mikroservis mimariye geçirirken sistemden yük atmak adına 3. parti bir yazılım ile izleme yapmaya karar verdik. İlk göze çarpanlar PRTG ve açık kaynak tarafında Zabbix. PRTG bir kaç saatte uzmanlaşabileceğiniz bir arayüze sahip ama lisanslı. Zabbix ise biraz daha emek istiyor. PRTG 100 sensöre kadar ücretsiz. İlgiliyseniz ikisine de bakın derim.

Kendi Geliştirdiğimiz Sistem Monitörümüz

Bilgisayar ve Hesap Yönetimi
Bu arada kullanıcı bilgisayarlarını yönetmek için teknik tarafta bir uygulama aramaya başladık. Bir müdürlükte pilot olarak Active Directory i denedik. Gördük ki bu sıkı sıkıya bağlı bir sistem. Eğer bunu kullanacaksak bir personeli bu işe adamak lazım. Sorunlarla karşılaşıldığında çözmesi zaman alıyor. Lisans bedelleri de cabası.

İkinci olarak Lider-Ahenk ‘e baktık. Bu biraz daha gevşek bağlı ve ücretsiz. Bunun yanında herkesi pardus ‘a geçirmek gibi nihai bir planımız var. Şuradaki yazıda bunun detaylarına biraz kafa yormuştuk. Bizim gibi küçük işletmelerde Lider Ahenk daha kullanılabilir geldi. Ar-Ge için bir kaç makine bir pilot ortam oluşturduk. Beklemedeyiz.

Yazlım Tarafı
Bir üst paragrafta da belirttiğimiz; kurumun yazılım işleri için kendi low code platform ‘umuzu yazdık: “Kübis|Bulut“. Bu platform coğrafi veri desteği ile -kısa sürede- kendi coğrafi bilgi sistemimizi oluşturmamıza bile izin verdi. Burada şunu söyleyeyim Bulut ismi kafamızı karıştırmasın. Bu -bilinen- kavramsal bulut değil. Bir işletim sistemi yazmadık. Sadece bir framework. Bulut ismini vermemizin nedeni; bu platform snmp ‘den ftp ‘ye, modbus ‘dan wms ‘e neredeyse bütün servisler ile konuşabiliyor; mobil uygulamadan, masaüstü uygulamalarına kadar her yazılıma altlık oluşturabiliyor, servis verebiliyor. İhtiyacımız olan herşeyi kapsadığı ve bizi lokasyon bağımlılığından kurtardığı için böyle isimlendirdik.

Bu bizim övündüğümüz en büyük çalışmamız. Front-End tarafı Php (Laravel) ile yazılsa da, C# ile yazdığımız bot modülü yada python ile yazdığımız senkronizasyon modülüne kadar bir çok dilin birleşimi denilebilir. Burada bu konuda bir yazı var. Yatayda ölçeklenebilen bir sistem olduğu için kullanıcı sayısı kısıtı yok. İstenilirse tüm Kütahya ‘ya bile hizmet verebilir. Bu şekilde tasarlandı. Bunu yazmayı bitirince hemen kurumun ihtiyacı olan her yazılımı bunun üzerinde tasarlamaya başladık. İzin işlemlerinden, stok takibine kadar onlarca modül geliştirdik. Kullanıcılar web arayüzünden login olup yetkisi dahilinde bunları kullanabilyorlar.

Kübis|Bulut (Monolith Hali)

İdari Ekranlar ve İş zekası
Ayrıca karar vericiler için yönetici ekranları tasarladık. Onlara maalesef “efendim size eğitim verelim kullanın” diyemiyorsun. Bir kaç tıklamada istediği veriye ulaşabilmeli. Yada sisteme akıtılan verilerle tasarlanmış raporlar hoş ve dinamik olarak gösterilebilmeli. Zaten en önemli amaçlardan biri karar vericileri yönlendirmek. Örneğin aynı marka model araçlardan birisi diğerlerine göre çok fazla yakıt tüketiyorsa bu tespit edilmeli. Bunu da angular fw ile tasarladık.

Kübis|Bulut idari ekranlar
Araçların akaryakıt tüketimleri.

Mobil Uygulama
Sonra mobil uygulamamızı geliştirdik. Standart kullanıcı işlemlerinden şöför personelin telefonunu araç takip cihazı olarak kullanmaya kadar bir çok modül de burası için yazdık. Burada Ionic frameworkü kullandık. Bu sayede hem ios hem de android için ayrı ayrı uğraşmaktan kurtulmuş olduk. Bunun yanında o zamanlar değişimiyle adından çok söz ettiren angular2 frameworkü test etme imkanımız oldu. İkisini de çok başarılı bulduk. İlerleyen süreçlerde java ve swift ile arge çalışmaları yapılmış olsak da hala ionic ile yazdığımız uygulamamız birinci sıramızda.

Masaüstü Uygulaması
Ardından kullanıcıların yerleşik ihtiyaçları için java ile masaüstü uygulamamızı yazdık. Burada da imza gerektiren işlemleri e-imza ile yapabilmerini sağlıyoruz. Bu süreçlerimizi hızlandırıyor. Bir örnek vermek gerekirse: personel araç talep yapıyor, müdürü onaylıyor, araç sevk amirliği de araç atıyor. Süreç tamamen e-imze ile ilerliyor. Personel ve şöför arkadaşa mobil bildirim gidiyor, Ayrıca şöför odasındaki monitöre de iş emri düşüyor. Bu sayede personel 5 dk içinde istediği yere yola çıkabiliyor.

IOT ve Elektronik
Yazılım tarafında bunları yaparken bir taraftan da IOT konusu ilgimizi çekiyordu. Arduino, Raspberry Pi, Orange Pi, NodeMCU… Bir sürü kart yaktık. Bir sürü devre tasarladık. Sunucu odamızdaki sıcaklık nem/kontrolü ile başlayan maceramız kameralı mesai takip cihazına kadar geldi. Hatta bir ara kendi pcb oyucumuzu tasarladık.

Kendi cihaz kutularımızı bile kendimiz tasarlayıp 3D yazıcı ile kendimiz basıyoruz. Yaptığımız projelerimizi de adım adım açık kaynağa açıyoruz.

Kameralı mesai takip cihazımız.

Yeni Kırılma
Ama durmuyor ki teknoloji bir yerde. Biz bu planlarımızı gerçeklerken o bizden daha hızlı gelişiyor. Bu noktaya kadar geldikten sonra bir kırılma daha yaşamamız gerektiğine karar verdik.

Dikkatimizi ilk Docker ‘ın gelişimi çekti. Sonra bunun sunucularımızın yükünü azaltacak bir yöntem olduğunu düşününce bayağı bi heyecanlandık. Mevcut monolith uygulamamızı mikroservislere bölmeye karar verdik. İlk olarak 3. parti servislerle sistemden atabildiğimiz kadar yük atalım sonra da kendi servislerimizi tasarlayalım dedik.

Docker ve İzleme
Docker swarm ile bir küme kurduk. Bu kümeye 250 adet kullanıcı bilgisayarını dahil etmeyi planladık. Hemen ardından servisleri yönetmek için ilk container olarak portainer servisini ayağa kaldırdır. Bu güzel bir yönetim arayüzü

Sonra aramaya inandık ve sistemi izlemek için güzel bir geliştirme bulduk. Bu, çeşitli 3. parti yazılımları kullanarak mikroversilerimizi ve docker nodelarımızı izlememizi ve alarm oluşturmamızı sağlıyordu. Github sayfası burada.

Grafana Monitor Aracı

Bunun ardından sahadaki cihazlarımızın sıhhat bilgisini de burada monitor etmeyi düşündük. Hemen yüksek erişilebilir bir MQTT kuyruğu oluşturduk. Bu abone mantığı ile çalışan bir kuyruk. Bu kuruğa abone olan bir python servisi yazdık. Aynı logstash(buna birazdan değineceğim) de olduğu gibi bu servis mqtt ‘den gelen mesajları alıp -grafananın bağlı olduğu- prometheus veri tabanına yazıyor. Sahadaki cihazlar da sıhhat bilgilerini peryodik olarak mqtt ye bağlı olan bir mesaj servisine yazıyor. Bu şekilde data grafanaya kadar getirilmiş oluyor.

Burada dikkat edilmesi gereken bence sıhhat mesajı iot cihaz içerisinden bağımsız bir servis ile gönderilmemeli. Bizzat iot cihazın ana uygulaması içinden gönderilmeli. Çünkü iot cihazı çalışıyor ama uygulama hata verip kapanmış olabilir. Uygulamada bir sıkıntı varsa sıhhat bilgisi -olması gerektiği gibi- gelmeyecektir. Zaten cihazın ping ve servis erişilebilirlik bilgileri yukarıda belirtilmiş olan ağ monitör uygulamasından izlenmektedir.

Log Servisi
Sonra ilk olarak monolith uygulamamızdan log servisini koparalım dedik. Tamamen bağımsız çalışıyor olması işimizi kolaylaştırdı. Ayrıca tüm logların tek bir havuzda toplanması bizim için ayrı bir güzellik oldu. Bir kuyruk yapısı kullanmaya karar verdik (Rabbit MQ). Monolith (front-end) uygulamamız direk bu kuyruğa yazacak, mobil, masaüstü uygulamaları ve iot cihazları ise bu kuyruğa yazma yetkisi olan bir servise yazma talebinde bulunacaktı. Sonra da nam-ı diğer çarlinin melekleri yani: Elestic Search, Logstash ve Kibana devreye girecekti. Logstash kuyruktan logları alıp elastic search e yazacak, kibana da bu logları istenildiğinde monitor edercekti. Artık istemcide başlayan süreç, sunucunun cevap hazırlarken geçidiği süreç, mikroservislerin eventler karşısında tutum sergilediği süreç tamamı alt alta incelenebiliyordu.

Ters Proxy
Ardından içerdeki servisleri yönetecek bir ters proxy olması gerektiğine karar verdik. Çünkü birden fazla alan adı ile bir sürü servise istek gelecek. Bunun için Traefik ‘i kullanmayı uygun bulduk. Aslında aynı işi yapabilecek Varnish servisi de var ama traefik in docker swarm için keşif aracı bizi büyük bir yükten kurtaracak. Biz sadece servisi tasarlayıp etiketleyeceğiz traefik bizim için keşfedip gelen istekleri buna yönlendirecek. Ayrıca load balancer özelliği de var ama bunu docker swarm da yaptığı için onu kullanmadık.

Ram Cache
Varnish zaten daha önceden aşina olduğumuz bir servis. Alameti fahrikası bir ram cache olması. 7-8 ms içinde cevap verebiliyor. Bunu da traefik arkasında harita katmanları gibi oluşturması çok maliyetli olan dataları sunmak için ara katman olarak kullandık. Data ilk sefer oluşturulduktan sonra hep bu servisten cevap dönecek.

Mevcut Servislerin Taşınması
Halihazırda ayrı bir vm olarak çalışan ve docker tarafında birebir karşılığı olan servisleri docker a taşımaya başladık. Bir postgresql cluster (1primary ve 1 replika)kurduk ve veritabanımızı taşıdık. Sonra da geoserver (harita sunucusu) ‘ı taşıdık. Geoserver gibi sadece okuma yapan servisleri replika veritabanından besledik. Bu da yükümüzü azalttı.

Kimlik Yönetimi
Kimlik yönetimi ve servislerin kimlik doğrulama işlemleri için kişilerimizi open ldap ‘a taşımaya karar verdik. Sonra bir kimlik doğrulama servisi yazıp tüm servislerin kimlik doğrulama işlemlerini buradan yapmasına karar verdik. Bu servis login olan kullanıcı billerini ortak bir redis servisine yazacak. Diğer servisler de istedikleri zaman kullanıcı bilgisini redisden teyit edebilecek. Bu sayede bağımsız servisler birlikte çalışabilecek.

Önce bu kimlik entegrasyonu için Tübitak ‘ın bir ürünü olan Engrek projesini kullanmak istedik. Aslında çok da ihtiyacımız yoktu ama bu tür “bizim ürünümüz” dediğimiz yerli ürünlerin yaygınlaşması güzel bişey. Ve bu şekilde gelişiyor. Sonra yaptığımız yazışmalarda engerek proje sorumlusu arkadaştan aldığımız “biz ücret mukabilinde sözleşme yaparak destek verebiliyoruz” cevabı bizi hakikaten üzdü. Kendilerine de söyledim bu işin düzelmesi için bunu her platformda, konuşmada, konferansta dile getireceğim. Bu vesile; engerek den vazgeçtik. Halihazırda yazmış olduğumuz data entagratör sınıfımıza ldap fonksiyonlarımızı ekleyip datayı manuel olarak aktardık. İki kaynağı da güncel tutmak için Kübis|Bulut uygulamamıza triggerlar eklemeye karar verdik. Mimarisi buna uygun.

İlk paragraflarda belirttiğimiz gibi kullanıcıların ldap da olması, Lider-Ahenk ‘i kullanmaya başladığımızda personelin bilgisayarına, sistemdeki kullanıcı adı ve şifre ile login olabilmesini de sağlayacak.

E-Hizmetler ve E-Devlet
Bayağı bir yol aldık sanırım. En azından bi kültür oturttuk dairede. Sonra dedik ki vatandaşa da yönelik birşeyler yapalım. Kurumda yaptığımız işlemleri internete açalım. Vatandaş evden yapabildiği herşeyi evden yapsın. Sonra bunu e-devlete entegre edelim. Baktık ki e devlette başka özel idare yok bu açıdan da sanırım ilk olacağız.

Burada Kübis|Bulut ‘u kullanacağımız yerler olacak. Ama tamamen projeyi bunun üzerine imar etmek istemedik. Çünkü mimarimiz gereği merkezde tek veritabanı var. Bunun üzerine mikroservisler yazmakla mikroservis olmuyor aslında, mikro api oluyo. Sistemi tamamen değiştirmek de riskli ve zaman alıcı. Nihai kararımız Kübis|Bulut ‘u hafifletebildiğimiz kadar hafifletip orada bırakacağız.

Bu e-hizmetlerin altyapısını kurmaya başladık. React ile gui yazmaya karar verdik. Kim bilir belki bir sonraki mobil uygulamamızı React Native ile yazarız. Biraz Flutter ile yarışşınlar bakalım 🙂

Redux ‘u üzerine entegre ettik ama bize biraz kulağımızı tersten tutmak gibi geldi. Redux u kaldırıp parçalar arasında daha basit bir yöntemle data akışı sağladık. Üzerine harita işlemleri için openlayers, ajax işlemleri için axios vs vs bir sürü kütüphaneyi test ettik. Bu da bizim gerçek büyük bir proje için ilk nodejs deneyimimiz oldu. Güzel de oldu.

Sonra madem node js ile başladık api servisini de burada yazalım bir kaç fw test edelim dedik. önce express.js ye baktık gayet başarılı ama mikroservis için özelleşmiş moleculer.js bize daha sıcak geldi. Express ‘i başka projeler için not ettik. En azından bir temel proje oluşması amacıyla tdd methoduna uyarak api yi ve bunun bağlı olduğu örnek bir servis olarak katmanlar mikroservisini yazdık. Bu bize hem geliştirme methoduna alışma olarak hem de sistemi gerçekleme konusunda arge oldu. Tamam dedik biz bunu kullanarak yapabiliriz. Yakın zamanda projeyi bu haliyle bir gerçek hayat örneği olarak acikkaynak.gov.tr ye atacağız.

Görsel biraz zayıf oldu idare edin. Biz ediyoruz 🙂

Önümüzdeki bir kaç ay e-hizmetler mikroservisleri ve e-devlet entegrasyonu ile uğraşacağız. Sonra yapay zeka konusunda birşeyler yapmayı planlıyoruz. Aslında tabela tanıma konusunda bu alana bir girizgah yapmıştık. Personeli, mesai takip cihazı ile çektiğimiz resimlerine bakıp, arkadaşının yerine kart okutan personeli müdürüne şikayet edecek.

Uzun vadede de dikkatimizi çeken konu blok zinciri. Hala nerede kullanabiliriz kısmındayız. Belki bir arge yapıp birden fazla müdürlüğü ilgilendiren konulardaki dataları tutmak için kendi blok zincirimizi yazabiliriz. Daha ileriki dönemde de eğer açık kaynak bir blok zinciri fw çıkarsa vatandaştan ve yüklenicilerden yapacağımız tahsilatları online olarak alırken bunu kullanabiliriz.

Bu saydıklarımızın hepsini yapmakta bize en büyük kolaylığı taşra ve küçük bir kurum olmamız sağladı. Bu sayede daha esnek hareket edebiliyor yada daha radikal kararları uygulayabiliyoruz. Bunun yanında bilgi işlem kurumun ana müdürlüklerinden birisi olsa iş yükü çok olacağı için yine buralara gelemeyebilirdik. Ayrıca bil vesile; bu süreçte bizi anlayıp üzerimizdeki angaryaları alan önümüzü açan müdürümüz Yavuz ÇAKIR ‘a da teşekkür ederim. Bu nimetlerin hepsinin farkındalığıyla kıymatini bilmeye çalışıyoruz. Fahreylerim…