Sorun giderme kurallarınız, sorun gidermeye yaklaşım? [kapalı]

Zor bir ağ / donanım / yazılım sorununu giderirken geri aldığınız genel kurallarınız var mı?

Örn: "İkinci bir bilgisayarla bir çevre birimi test ederek sorunun kaynağını izole ediyorum" veya "Aygıtı çalıştırmak için mümkün olduğu kadar çok donanımı kaldırıyorum ve sonra sorunu yeniden üretene kadar bileşenleri birer birer ekliyorum" , vb.

Bir süre sorun yaşadıktan sonra kendime yazdığım noktaların bir listesi:

1. Asıl amacın nedir? Açıkça ve kesin olarak belirtilmelidir. Hedef çok özel olmalı. Genel olmamalı. Tercihen bir cümle .
   
2. Senin problemin ne ?
   
3. Sadece bir tane sorun mu var? Çok sayıda varsa, bunları birer birer çözün.
   
4. Sorunu farklı koşullarla tekrarlamaya çalışın . Mümkün olan tüm koşullarda çoğaltılabilir mi, kopyalanamaz mı? Sorunun doğası hakkında bir şey söylüyor mu?
   
5. Acil bir sorun varsa bir geçici çözüm var mı? Mümkün olduğunca çok sayıda geçici çözüm bulmaya çalışın.
   
6. Sorununuzun nedeni ne olduğu konusunda mümkün olduğunca fazla tahmin yapmaya çalışın .
   
7. Tahminlerinizi kanıtlamaya çalışın , sistemi deneyin .
   
8. Ne yapmaya çalıştığınıza sadık kalın . Bir seferde bir şey yapın.
   
9. Takip edin Zaten denedim ne yaptığını ne.
   
10. Do sapma birincil amacından. Farklı bir sorunu değil, asıl sorununuzu çözüp çözmediğinizi sürekli olarak kontrol edin.
    
11. Ya da düzeltmeyin .

Ayrıca hata ayıklama kurallarının harika bir listesi vardı, kuralların her biri için örnekler ve açıklamalar içeren bir PDF biçimindeydi. PDF'yi hızlı bir şekilde bulamadım, ancak listenin bir posteri olduğunu düşünüyorum:

• Sorun İnternet ile ilgili ise, muhtemelen DNS'dir.

• Sorunu teşhis etmek zorsa, muhtemelen RAM'dir.

• Sorun bir Windows iş istasyonundaysa, yeniden boyutlandırmak muhtemelen en hızlı yoldur.

• Sorun Cuma günü ise, muhtemelen ciddi bir şey.

Bilimsel yönteme geri dönmeyi seviyorum .

Gönderen ( http://en.wikipedia.org/wiki/Scientific_method )

1. Soruyu tanımlayın
2. Bilgi ve kaynakları toplayın (gözlemleyin)
3. Form hipotezi
4. Deneme gerçekleştir ve veri topla
5. Veri analizi
6. Verileri yorumlamak ve yeni hipotezler için başlangıç ​​noktası teşkil eden sonuçları çıkarmak
7. Belge Sonuçları

Genel bir kural olarak, temel varsayımlarımı her zaman kontrol etmeye çalışıyorum. Gücü var mı, fişi takılı mı, kablo bağlantısı iyi. Gevşek bir kablonuz olduğunda bir yazılım sorununa bakmaya çalışmak için saat harcamak çok can sıkıcıdır.

Hipotez oluşturma aşamasında, problemin elimden geldiğince olası nedenlerini ortaya çıkarmanın çok önemli olduğunu düşünüyorum. Sonra, test etmenin ne kadar kolay olduğuna ve fikrin ne kadar muhtemel olduğuna bağlı olarak önce test edilecek fikirleri seçmeye çalışıyorum.

Yardım almak da önemlidir. Yapabiliyorsanız, iş arkadaşlarınıza, satıcınıza veya söz konusu sistemler hakkında en bilgili kimseye danışın. Sorunu çözmenize yardımcı olabilecek bir kişi varsa, tekerleklerinize bir problem üzerinde çok fazla zaman harcamayın.

O'Reilly'nin, bilimsel yönteme çok benzeyen ve izlenmesi gereken iyi bir adım olan Ağ Sorun Giderme Araçları adlı iyi bir kitabı var. Kitabı çok faydalı buldum ve şiddetle tavsiye ediyorum. Kitap daha fazla ayrıntıya giriyor ve birçok yararlı araç sunuyor.

Gönderen Ağ Sorun Araçları

1. Hedefini belirt
2. Sistemi tanımla
3. Muhtemel sonuçları belirle
4. Neyi ölçeceğinizi tanımlayın ve seçin
5. Uygunsa, test parametrelerini ve faktörlerini tanımlayın
6. Araçları seç
7. Ölçüm kısıtlamaları oluşturun
8. Deneysel tasarımı inceleyin
9. Veri topla
10. Veri analizi

Ayrıca bakınız:

• 3COM'da bir sorun giderme kılavuzu var
• Murphy kanunu - Yanlış gidebilecek herhangi bir şey var.
• Occam's_razor - Diğer tüm şeyler eşit olduğunda, en basit çözüm en iyisidir.

(Bu vurgu, " Sistem ve Ağ Yönetimi Uygulaması " nın "Hata ayıklama" bölümünden alıntılanmıştır )

Bilmeniz gereken iki şey:

1. "Sabit" versiyonun neye benzediğini bilin. Tercihen işler çalıştığında belli bir çıktı veren çalıştırabileceğiniz bir komut. Örneğin: Anahtarları doğru kurduğumda SSH'nin neden bir şifre istediğini anlamaya çalışıyorum (ya da öyle düşündüm). Öyleyse testim: "ssh servername uptime" ve bir şifre sormadan çalışması gerekiyor.

2. Problemi doğru seviyede tanımlayın. Bir sunucuya ping atmadıklarından şikayet eden bir kullanıcı, sunucuyu çalıştırmak ve düzeltmek için sizi göndermemelidir. Kişinin işi, bütün gün oturup bir makineye ping atmak değildir. Makineyi DNS sunucusu olarak kullanmak gibi bir iş yapmak istiyorlar. Örnek: Bir kullanıcı bir makineyi dünya çapında yarı yolda kullanamadığından şikayet edince. Günü, makinenin neyin yanlış olduğunu bulmak için şirketin o bölümündeki sistem yöneticilerini takip ederek geçiriyorum. Görevden alındı ​​ve panik içindeydiler, çünkü yanlış makineden güç aldıklarını düşünüyorlardı. Kullanıcıyla iletişime geçtim ve "Bu makineye ping atmaya ihtiyaç duymanın yanı sıra, onunla ne yapmak istersiniz?" Dedim. Üzerinde belirli bir işi yapmak istediği ortaya çıktı ve uygun prosedürü uygulamış olsaydı, görevleri otomatik olarak değiştirme makinesine yönlendirilirdi. Bütün günümü ve yerel sistem yöneticilerinin zamanını boşa harcadım. "Pingleyemiyorum" nin bir başka nedeni de test edilecek doğru şey değil: Genellikle güvenlik duvarları, ping paketlerini bırakacak ancak diğer paketlerin geçmesine izin verecek şekilde yapılandırılmıştır. Yaşamak istediğinizi test edin.

İki strateji:

1. Katkı Maddesi: Sorun başlayana kadar bileşen eklemeye devam edin. En son eklediğiniz sorun. Örnek: Web tarayıcıları bir sunucuyla konuşamıyor. Sunucu ile kullanıcı arasında yük dengeleyici, güvenlik duvarı, önbellek ve kullanıcının yerel web proxy'si bulunur. Önce her defasında bir bileşen ekleyerek sorguları doğrudan sunucuya, ardından LB üzerinden sunucuya, ardından güvenlik duvarı ile LB'ye, vb.

2. Çıkarma: Sorun çözülene kadar bileşenleri sökmeye devam edin. Kaldırdığınız son şey sorun oldu: Örnek: Düzinelerce kartı olan bir makine önyükleme yapmıyor. Makine önyüklenene kadar kartları çıkarmaya devam edin.

İki parça aptal şans:

1. Söylediğim her şeyi unut. Problem, sistemde yapılan son değişikliklerden kaynaklanıyor. (Bu, zamanın% 99'unda işe yarıyor ... sorun şu ki, son değişimin gerçekte ne olduğunu bilmediğin zamanın% 99'u

2. Her şey başarısız olduğunda, aptal şeyleri kontrol edin. http://whatexit.org/tal/mywritings/dumb-things-to-check.html Örnek: Çılgın bir problem henüz açıklanamadı. Sonra yapılandırma dosyasını kontrol ettik: bir kullanıcı bir Windows kutusuna kopyalayıp düzenleyerek ve ardından geri kopyalayarak düzenledi. Şimdi her satırın sonunda bir ^ M vardı. Hiç fark etmedik çünkü metin editörümüz sessizce bu gerçeği sakladı. Ne yazık ki, konfigürasyon dosyasını okuyan yazılım, bu ^ Ms’yi, tonlarca başka prosedürle sonuçlanan kesintisiz bir alana dönüştürdü.

Tüm süreç boyunca hatırladığım genel uygulamalar:

1. Yaptığım her şeyi yaz.
2. Bir seferde sadece bir değişiklik yapın.
3. Mümkünse, kesin bir ilerleme kaydedilmedikçe, başka bir denemeden önce değişikliği tersine çevirin.

Burada sorun giderme sırasında temel metodolojimi tanımlar:

• Sistem çalıştığında ve çalıştığında, bir sorun olmadan önce ne yaptığını görmeye çalışıyorum. Joe Richards neden bu kadar kısa sürede benden daha iyi olduğunu açıklıyor .
• En basit çözümle başlıyorum. Örneğin, ağ bağlantısı yok mu? Fiziksel katmanı kontrol edin. Size kaç kez aralıklı bağlantı sorunlarının bir sunucu sorunu olmadığını ya da yarı yarıya ya da ters giden bir ağ kablosunu söyleyemem.
• Değişiklik yapmaya başlamadan önce olası tüm kaynaklardan görebildiğim tüm belirtileri yakalamaya çalışıyorum.
• Ön tanı testlerini yapıyorum. Örneğin, bir sunucu kapalıyken, ilk yaptığım şey bunu doğrulamak için ping ve nbtstat (Windows) kullanmak. Sorun uzak bir noktada olabilir (eski bir Hava Kuvvetleri teknik kontrolünün sözlerini ödünç almak için).
• Araştırma yapmaktan korkmuyorum. Google, support.microsoft.com, eventid.net ve benzeri siteler arkadaşınızdır.
• Topluluktan yardım istemekten korkmuyorum. Sadece serverfault.com gibi siteler değil, Twitter'da güvendiğim ve saygı duyduğum kişilerle de bağlantıda bulunduğum bir çok insan var.
• Gördüklerimle bulduğum cevapları değerlendiriyorum. Çözümde bildirilenle ilgili gördüğüm kanıtları yeterince göz önünde bulundurarak herhangi bir çözümün doğru çözüm olduğunu sanmıyorum.

Tutmaya çalıştığım tutumlar:

• Sebep ve sonuç veren mutlak güven işe yarıyor ve hiçbir şey sihir değil. Hiçbir şey olmuyor ki bu gerçekten garip, sadece anlamadığım şeyler.
• Eğer onu zorlamaya devam edersem, çözüleceğini kesin olarak söylerim (bu daha bilgili birine, öğrenmeye, yardım istemeye, sıkı çalışmaya vb. Sahip olabilir).
• Bir kurulumun, programın veya senaryonun kötü bir şekilde nasıl tasarlandığı veya gerçekten aptalca olduğu hakkında homurdanan, sadece işe yaramadığı için yapmayın. (Bunu zor buluyorum, homurdanmak eğlencelidir).

Bunlar benim tutmam için yararlı olan tavırlar - kollarımı havaya fırlatmamı, "tuhaf" bir şey ilan etmemi, sonra vazgeçmemi veya mutsuz olmama neden olduklarını, çünkü "çözülemez" hissini vermemi sağlıyor.

Sorun giderme hakkında düşünme yolları:

• Sistemler birbirine bağlanırsa veya rastgele yapılandırılırsa birçok parçaya sahiptir, sonra istendiği gibi çalışmazlar. İşe yarayacak bir veya iki özel yapılandırma var - tuğlaları ve metalleri kazmak için milyonlarca yoldan, yalnızca birkaçı köprüler ve yalnızca bir ya da iki tanesi yeterince iyi köprüler. Bunun nedeni bir metin dosyasındaki bir karakter veya başarısız bir sunucu olabilir, ancak her bölüm her şeyin doğru olması için doğru olmalıdır. Gerekirse ayrıntılı ve titiz olmaya istekli olmam gerekiyor. Sistemler “gösteri devam etmeli” diyemez.
• Harita gibi tüm bir sistemle başlarsınız, “sorunun nerede olduğunu” temsil eden harita üzerinde kayan bir olasılık bulutu görürsünüz ve işiniz deneyimi kullanmak ve olasılığı bazı alanlardan uzağa itmek için testler bulmaktır ve Olasılık problemi yüksek olan noktalara yoğunlaştırmak, sonra bunlara saldırmak. Bu, sonuç ve sonuç noktasına geri döner - sorun sistemdedir, sihir değildir. Bu var olan bir problem, bu yüzden bir yerde var olması gerekiyor.
• Her şey, istediği gibi kurulabilir. Bir davranışı “Tamam”, diğeri “sorun” olarak tanımlamamızın tek yolu, birinin ne istediğinin olmamasıdır. Ne istediklerini, neyin net ve özel bir şekilde aldıklarını anlamalısınız.

Sorun giderme süreci:

• Sorun nedir. Gerçekleştiğini gördüğünüzden ve kendiniz çoğaltabildiğinizden emin olun, böylece herhangi bir yanlış anlaşılma olmaz. Sık sık sorunlar bana geldiğinde yardım masamızdaki birçok insandan geçti, hala kimse bana sorunun gerçekten ne olduğunu açıklayamıyor.
• Tekrarlayan iftiralar yeniden başlıyor - bölün ve ele geçirin, ikili arama - sorunun testin bu tarafı mı yoksa o taraf mı olduğunu kanıtlayacak bir test ile geldiniz ve testi mümkün olduğunca ortadan kaldıracak bir test ile geldiniz. Çözülene kadar tekrarlayın.
• Bundan kaçınabileceğinizi öğrenmeyin - veritabanı hesabını kilitlemek ve veritabanının nasıl kullanıldığını öğrenmek için saatler harcayarak veritabanına dahil olmadığında sorunun hala devam ettiğini kanıtlamak daha iyidir.
• Kendimi "daha sonra ne yapacağımı bilmiyorum" diye düşünerek bulmak çok kolay. Bunun ne zaman olduğuna dikkat edin ve sorunu belirleyen testlerle tekrar karşılaşın.

İnternet çalışmıyor mu? Sorunu kontrol et, ulaşamadıkları bir web sitesi bul. Hızlı testler internet bağlantılarını içerir (çalışır), benim için yükler mi (hayır). Hızlı testler site olduğunu gösteriyor. Sorunun benim için gerçekleştiğini görerek, olasılıkları bilgisayarlarından, tarayıcılarından, DNS'lerinden, kullanıcı hesap ofisleri güvenlik duvarlarından, vb. Hızlı bir şekilde uzaklaştırdım.

Yani site yüklenmiyor, şimdi ne? Bu henüz düzeltilemez, bu yüzden problemi daha küçük bir yere koyacak yerlere bakın. Sunucu açık mı? Ping mi? DNS çalışıyor mu? Evet. Servis 80 numaralı bağlantı noktasında cevap veriyor mu? Hayır. Servis çalışıyor mu? Hayır. Başlıyor mu? Hayır. Olay günlüğünde / günlük dosyalarında hata veriyor mu? Evet! Ne diyorlar?

Bu verimli ve hızlı bir sorun gidermedir çünkü sorunun kapsamını daraltmaya odaklıdır. İnternetin çalışmadığına dair raporlarını kabul edersem, bunun bir bağlantı hatası olduğunu düşünmem konusunda yanlış yönlendirilirdim. İlk görüşümü onlar için yüklenmediğini kabul edersem, onların hatalı olduğunu düşünerek bilgisayarlarına zaman harcardım.

Olabildiğince büyük "olamayacak şeyler" parçalarını oy.

Sistemi anlamak. Bir sistem hakkında ne kadar genel bilgiye sahibim, o kadar kolaylaşır. Zayıf bir anlayışa sahip olduğumda, sorunlar daha korkutucu, daha zor, daha yavaş ilerliyor ve bir düzeltmeden daha geçici bir çözümle bitirme olasılığı ya da küçük, kesin bir cerrahi düzeltmeden daha büyük bir aptal yavaş düzeltmeyle (yeniden yükleme) daha muhtemel.

Genel olarak “Bu soruna neden olabilecek ne değişti” sorusunu soruyorum. Çoğu sorun bilinen iyi yapılandırmalardaki değişikliklerden kaynaklanır. Değişikliği kimin yaptığını tecrit edebilirseniz, genellikle cevabınızı alırsınız.

Bence bu bir yetenek değil, bilim değil. Yanlış yoldan aşağıya indiğiniz zamanlar vardır ancak çoğu zaman:

• İlgili tüm teknolojileri (ağ, donanım, işletim sistemi, yazılım, geliştirme vb.) İyi bir temel anlayışa sahip olmak, bu "yanlış yolları" ortadan kaldırmanıza yardımcı olacaktır.
• basit düşünün - en karmaşık senaryoya atlamayın, çünkü kafanızdadır, temel sorun giderme işlemlerinizi gerçekleştirin ve size yol göstermesine izin verin.

Bir keresinde patronum beni telefonda "kıdemli" bir mühendisle aramıştı - bana bağlanamayan bir sunucusu olduğunu ve kabloyu değiştirmeyi denediğini ama yine de neşe duymadığını söylüyordu. Akülerde bir UPS gibi arka planda bip sesi duyabiliyordum. Anahtar üzerinde etkinlik görüp göremediğini sordum, hayır dedi. Bip sesinin UPS’den gelip gelmediğini sordum, evet dedi, ona rafta hiç ışık görüp göremediğini sordum hayır dedi ... Burnunun ötesine bak - yardımcı olur!

Açık olanı kontrol ederek başlıyorum. Sorunun ne olduğunu açıklayan bir hata mesajı var mı? Her şey düzgün bağlanmış mı? Birkaç saat içinde çözülebilecek bir sorunu gidermek için birkaç saatimi harcamaktan hoşlanmıyorum. Bence çok sistemli olmak mümkün. Sorunun tam olarak ne olduğunu söylesem de, insanların bir sorunu çoğaltarak bir gününü boşa harcadığını gördüm. Onlara bunun için para ödüyorum.

Cevap açık değilse, bazı şüphelileri sıralayın ve önce bunları test edin. Sadece olası şüphelileri test ettikten sonra, olası şüphelileri test etmelisiniz. O zaman istediğiniz kadar bilimsel olabilirsiniz.