Üretimde Sorun Gidermeyi Hızlandırmak İçin 7 Hata Ayıklama Tekniği

Bir uygulamaya üretim desteği sağlamak, yazılım geliştirmenin en zorlu yönlerinden biridir. Geliştiriciler bakım ekibine atanır ve uygulamadaki hataları düzeltmeye çalışır. Bununla birlikte, bir üretim kesintisi olması durumunda çağrı üzerine de kullanılabilirler ve bu durumda uygulamayı mümkün olan en kısa sürede tekrar rayına oturtmak için çalışırlar.

Bu makale, üretimdeki hataları önleyebilmeniz ve sorunları çok daha hızlı bulabilmeniz için bir dizi özel öneri sunmayı amaçlamaktadır. Bu uygulamaları üretimde işlemek karmaşık bir iştir: Genellikle hiçbir belge yoktur, uygulama eski bir teknoloji yığınına yazılmıştır veya her ikisi birden. Çok az eğitim seansı vardır ve hakkında çok az şey bildiğiniz bir uygulamaya destek sağlamak için çağrılmak yaygındır.

Çoğu geliştirici, üretimdeki bir uygulamayı işleme deneyimine sahip değildir. Üretim ortamlarında meydana gelen ve hatalara ve kesintilere neden olan ve genellikle şirkete binlerce ve bazen milyonlarca dolar gelir kaybına neden olan bir dizi sorun vardır. Ayrıca, geliştiricilerin çoğunluğu çevreye maruz kalmadığından, sırayla bu sorunlara neden olacak bazı hatalar yapmaya devam ederler. Bu ipuçları listesi, üretim deneyiminden öğreterek işinizi daha az acı verici hale getirmelidir.

1. İpucu: Uygulamanın çalışması için gereken tüm yapılandırmayı kaldırın veya otomatikleştirin.

Yazılımın yeni bir sunucuya yüklenmesi için ne kadar yapılandırma gerekiyor? Geçmişte, ekipte her yeni geliştirici olduğunda bu işlemin tamamlanması bazen üç gün sürebilirdi. Uygulamayı yüklemek, manuel olarak gerçekleştirilmesi gereken birçok adım gerektirecektir. Zamanla, yazılım bu talimatlarla uyumsuz hale gelen yeni sürümlere dönüşür ve elbette talimatlar genellikle güncellenmez. Aniden, uygulamayı başlatmak ve çalıştırmak için gerekenden çok daha fazla zaman harcıyorsunuz.

Konteynerleştirmenin ortaya çıkmasıyla birlikte, sıfır yapılandırmayla ve Docker görüntüsü bağımsız olduğundan, çok daha düşük bir oranda çalıştırmanız gibi ek faydayla bir uygulamayı hemen çalışır duruma getirmenin bir yolunu sağlamak çok daha kolay hale geldi. kullanılan işletim sistemi, diller ve çerçevelerin farklı sürümleriyle ilgili sorunlarla karşılaşma riski.

Benzer şekilde, geliştirici kurulumunu basitleştirin, böylece IDE kurulumu dahil olmak üzere çalışır duruma gelmesi fazla zaman almaz. Bir geliştirici, sıfırdan kahramana 30 dakikadan daha kısa sürede gidebilmelidir.

Bir üretim sorunu olduğunda, bazen en iyi uzmanlarınız müsait olmayabilir (örneğin, tatil veya hastalık) ve soruna kimin attığınızı, hem de hızlı bir şekilde çözmesini istersiniz.

2. İpucu: Teknoloji yığını çorba tuzağına düşmeyin.

Ne kadar az teknoloji kullanılırsa o kadar iyi. Tabii ki, bazen iş için doğru aracı kullanmanız gerekir. Ancak, “doğru araçlara” aşırı yüklenmemeye dikkat edin. İçme suyu bile çok fazla içilirse ciddi sağlık sorunlarına neden olabilir. Teknoloji yığınına eklenen her yeni dil ve çerçeve, etkileri dikkatli bir şekilde göz önünde bulundurarak açıkça tanımlanmış bir karar verme sürecinden geçmelidir.

• Bir StringUtils sınıfına ihtiyacınız olduğu için yeni bir çerçeve bağımlılığı eklemeyin.
• Dosyaları taşımak için hızlı bir komut dosyası yazmanız gerektiği için tamamen yeni bir dil eklemeyin.

Büyük bir bağımlılık yığını, kitaplıklar uyumsuz hale geldiğinde veya çerçevelerin kendilerinde veya geçiş bağımlılıklarında güvenlik tehditleri bulunduğunda hayatınızı perişan edebilir.

Ayrıca, eklenen yığın karmaşıklıklarının ekip için yeni geliştiriciler bulmayı ve eğitmeyi zorlaştırdığını unutmayın. İnsanlar başka şirketlerde yeni rollere geçerler ve yenilerini bulmanız gerekir. Mühendislik ekiplerinde ciro çok yüksektir, hatta harika avantajlara ve iş-yaşam dengesi muamelelerine sahip olduğu bilinen şirketlerde bile. Yeni ekip üyesini olabildiğince çabuk bulmak istiyorsunuz. Teknoloji yığınının üzerine eklenen her yeni teknoloji, yeni bir aday bulma süresini uzatır ve yeni işe alımları giderek daha pahalı hale getirme potansiyeline sahiptir.

İpucu #3: Günlüğe kaydetme, sizi gereksiz ayrıntılarla boğmamalı, sorunu bulmanıza rehberlik etmelidir.

Günlüğe kaydetme, yorumlara çok benzer. Alınan tüm kritik kararların yanı sıra hata ayıklama tekniklerinizde kullanılacak tüm bilgileri belgelemek gerekir. Basit değil, ancak biraz deneyimle, birkaç olası üretim kesintisi senaryosunun haritasını çıkarmak ve ardından en azından bunu çözmek için gerekli günlük kaydı yapmak mümkündür. Tabii ki, günlüğe kaydetme, ne tür sorunların ortaya çıktığına bağlı olarak kod temeli ile birlikte gelişir. Genel olarak konuşursak, oturum açma işleminizin %80'ini kodunuzun en önemli %20'sinde, yani en çok kullanılacak kısımda olmalıdır. Örneğin önemli bilgiler, bir yönteme iletilen argümanlardan alınan değerler, alt sınıflardan çalışma zamanı türleri ve yazılım tarafından alınan önemli kararlar, yani bir yol ayrımında olduğu ve sol veya sağı seçtiği zamandır.

4. İpucu: Beklenmeyen durumlarla başa çıkın.

Kodun varsayımlarının ne olduğunu çok net bir şekilde haritalayın. Belirli bir değişkenin her zaman 2, 5 veya 7 değerlerini içermesi gerekiyorsa, bunun int değil enum türünde olduğundan emin olun. Büyük üretim kesintilerinin bir numaralı kaynağı, belirli bir varsayımın başarısız olmasıdır. Herkes sorunu yanlış yerde arıyor çünkü birkaç şeyi hafife alıyorlar.

Varsayımlar açıkça belgelenmeli ve bu varsayımlardaki herhangi bir hata, üretim destek ekibinin durumu hızla düzeltebileceği kadar alarm vermelidir. Verilerin geçersiz bir duruma gitmesini veya en azından bu durumda bir tür uyarı oluşturmasını önleyecek bir kod da olmalıdır. Belirli bilgilerin bir kayıtta saklanması gerekiyorsa ve aniden iki kayıt varsa, bir uyarı ateşlenmelidir.

İpucu #5: Bir müşterinin başına gelen bir sorunu tekrarlamak kolay olmalıdır.

En zor adımlardan biri her zaman müşterinin karşılaştığı sorunu tekrarlamaktır. Çoğu zaman, zamanın %95'ini sorunu çoğaltmaya çalışarak harcarsınız ve ardından sorunu çoğaltabildiğiniz anda yama, test etme ve dağıtma dakikalar meselesidir. Bu nedenle, uygulama mimarı, sorunları çoğaltmanın son derece basit ve hızlı olduğundan emin olmalıdır. Bunun çoğu, müşterinin içinde bulunduğu duruma ulaşmak için geliştiricinin önemli miktarda uygulama yapılandırması yapması gerektiğinden olur. Müşterinin içinde bulunduğu durumu bir araya getiren, depolanmış birçok kayıt vardır; sorun, geliştirici olarak sizin müşterinin tam olarak ne yaptığını tahmin etmeniz gerektiğidir. Ve bazen, yalnızca sonuncusunu hatırladıkları bir dizi adım gerçekleştirdiler.

Ayrıca müşteri, sorunu ticari terimlerle açıklayacak ve geliştiricinin daha sonra teknik terimlere çevirmesi gerekecektir. Ve geliştiricinin uygulama ile daha az deneyimi varsa, henüz eksik ayrıntıları bile bilmediğinden, eksik ayrıntıları sormayı bilmeyeceklerdir. Tüm üretim veritabanını makinenize kopyalamak mümkün değildir. Dolayısıyla, durumu simüle etmek için gerekli olan sadece birkaç kaydı üretim veri tabanından hızlı bir şekilde içe aktaracak bir araç olmalıdır.

Müşterinin Siparişler ekranıyla ilgili bir sorunu olduğunu varsayalım. Siparişlerinden birkaçını, müşteri kayıtlarını, bazı sipariş detay kayıtlarını, sipariş konfigürasyon kayıtlarını vb. içe aktarmanız gerekebilir. Ardından, bunu bir Docker örneği içindeki bir veritabanına aktarabilir, bu örneği başlatabilir ve aynen böyle, müşterinin gördüğü şeyin aynısını görmek. Elbette tüm bunlar, hiçbir geliştiricinin hassas verilere erişimi olmadığından emin olmak için uygun özenle yapılmalıdır.

İpucu #6: Kesme noktalarının uygulamada nereye yerleştirileceği açık olmalıdır.

Müşteri ekranınız varsa, o ekranda bir sorunda hata ayıklamak için kesme noktaları yerleştirebileceğiniz bazı Müşteri nesneleri olmalıdır. Bazen geliştiriciler soyutlama ateşine kapılır ve kullanıcı arayüzü olaylarının nasıl ele alınacağına dair inanılmaz derecede akıllı kavramlar bulurlar. Bunun yerine, her zaman KISS ilkesine (Keep it Simple, St- er, Silly) güvenmeli ve UI olayı başına kolayca bulunabilen bir yöntemimiz olmalıdır. Benzer şekilde, toplu işleme işleri ve zamanlanmış görevler için, kodun çalışıp çalışmadığını değerlendirmek için yer kesme noktalarının nerede olduğunu belirlemenin kolay bir yolu olmalıdır.

İpucu #7: Tüm dış bağımlılıkların açıkça belgelendiğinden emin olun.

İdeal olarak, belgelerin kaybolmaması için bunu kaynak kontrol sistemindeki BENİOKU dosyasında yapın. Uygulamanın düzgün çalışması için mevcut olması gereken tüm harici sistemleri, veritabanlarını veya kaynakları belgeleyin. Ayrıca, bunlardan hangilerinin isteğe bağlı olduğuna dikkat edin ve isteğe bağlı olduklarında ve kullanılamadıklarında nasıl ele alınacağına ilişkin yönergeler ekleyin.

Hata Ayıklama Tekniklerinin Ötesinde

Yeni özellikler oluştururken veya bir sisteme bakım sağlarken bu önerilere uyulduğunda, üretim desteği çok daha kolay hale gelecek ve şirketiniz çok daha az zaman (ve para) harcayacaktır. Bildiğiniz gibi, üretim hatalarını ve çökmelerini giderirken zaman çok önemlidir - kaydedilebilecek her dakika, sonuçta büyük bir fark yaratır. Mutlu kodlama!