48 port, 48 kez el işi. Yöneticinin günü mü gitti?
Bugün yeni bir switch'i port port, satır satır yapılandırıyorsunuz. Yazılan her satır olası bir rakam hatası. COD, birçok tekil adımdan tek bir rollout komutu üretir ve onu Ansible ile doğrudan platformdan uygular, okunabilir loglarla, çok kiracılı ve on-premise.
Haftalık görünümde bakım takvimi: planlı bakımları merkezi olarak zamanlayın.
Tanıdık geldi mi?
48 port, 48 kez el işi: switch yapılandırması yöneticinin gününü yiyor
Sorun: Rack'e yeni bir access switch gelir ve angarya başlar: port port yapılandırmak, CLI'da satır satır ya da web arayüzünde tık tık. Birden çok switch'te bu saatlerce sürer.
Sonuç: Rollout'lar gereksiz yere uzar ve nitelikli yöneticileri sıkıcı tekrar işine bağlar. Yazım hataları çoğu zaman ancak bir kullanıcı ağa erişemeyince fark edilir, hata arayışı da baştan başlar.
COD bunu şöyle çözer: COD, 48 tekil adım yerine tüm port aralığı için tek bir rollout komutu üretir (örn. 1/0/1'den 1/0/48'e kadar portlar tek seferde) ve yapılandırmayı Ansible ile doğrudan platformdan, araç değiştirmeden uygular. Bu, tıklamadan tasarruf ettirir, yazım hatalarını önler ve dağıtımları belirgin şekilde hızlandırır.
Her planlı bakım yanlış alarma dönüşüyor ve ekip duyarsızlaşıyor
Sorun: Bakım penceresi haftalardır planlı, yine de ilk host yeniden başlar başlamaz izleme alarm verir. Ekip beklenen bildirimleri onaylayıp geçer. Ya da bakım sırasında alarmları toptan yok saymaya alışır.
Sonuç: Yanlış alarmlar zaman kaybettirir ve her izleme sinyaline duyulan güveni aşındırır. Alarmları rutin olarak kapatan, bir gün asıl önemli olanı kaçırır.
COD bunu şöyle çözer: Planlı bakımları merkezi olarak COD takviminde zamanlarsınız. Bakım penceresi boyunca izleme sebepsiz alarm vermez. Planlı işleri gerçek arızalardan güvenilir biçimde ayırırsınız ve her alarma duyulan güven korunur.
Kayıtsız otomasyon çalıştırmaları: "Bunu kim uyguladı?"
Sorun: Bir rollout'tan sonra bir şeyler yolunda değildir. Ama hangi çalıştırmaydı, kim başlattı, sonuç ne oldu? Yanıt, varsa bile, kimsenin gönüllü okumadığı ham JSON çıktılarında saklıdır.
Sonuç: Temiz izlenebilirlik olmadan her hata arayışı gereksiz yere uzar. Altyapıdaki değişiklikler eksiksiz belgelenemediği için KRITIS denetiminde de bulgu riski doğar.
COD bunu şöyle çözer: COD, Ansible çıktılarını ham JSON yerine biçimlendirilmiş ve rahat okunur gösterir. Her log kaydı kendi runner ID'sini taşır, böylece her çalıştırma net biçimde izlenebilir kalır: kim, ne zaman, neyi, hangi sonuçla uyguladı. Bu, KRITIS'e ve denetime uygun bir izlenebilirliktir.
Neden COD, sadece bir özellik değil
COD'da otomasyon, işletmenizle aynı platformda çalışır: rollout'ları etkiledikleri varlıkların hemen yanından başlatırsınız ve bakım takvimini izlemeyle paylaşırlar. Bu yüzden platform, bir işin ne zaman planlı olduğunu ve ne zaman gerçek bir arıza bulunduğunu bilir. Araç değiştirmeden Ansible, runner ID'li okunabilir loglar, çok kiracılı ve on-premise.
Sıkça sorulan sorular
Saatler yerine saniyeler içinde rollout.
Bir canlı demoda toplu rollout'u, bölge resync'ini ve bakım takvimini kendi ortamınızda uygulamaya yakın biçimde gösteririz, ya da tüm işlevleri derli toplu içeren otomasyon veri sayfasını indirin.