Sahip olduğunuz sistem yöneticisi kazalarının eğlenceli hikayelerini arıyorum. CEO'nun e-postasını silme, yanlış sabit sürücüyü biçimlendirme, vb.
Kendi hikayemi cevap olarak ekleyeceğim.
Sahip olduğunuz sistem yöneticisi kazalarının eğlenceli hikayelerini arıyorum. CEO'nun e-postasını silme, yanlış sabit sürücüyü biçimlendirme, vb.
Kendi hikayemi cevap olarak ekleyeceğim.
Linux "killall" komutu arasındaki farkı keşfettim (belirtilen isimle eşleşen tüm süreçleri öldürür, zombileri durdurmak için yararlıdır) ve solaris "killall" komutu (tüm süreçleri ve sistemi durdurur, üretim sunucusunu durdurmak için yararlıdır) en yoğun saatlerin ortası ve tüm iş arkadaşlarınızın bir hafta boyunca size gülmesini sağlayın).
Netscape'in ürünü olan kurumsal web proxy'mden sorumluydum. Yönetici formları etrafında oynarken (bu bir web tabanlı bir arayüz oldu) büyük bir vardı (ve yemin ederim kırmızı) düğmesi Kullanıcı veritabanını sil. Sorun değil, düşündüm. Bana verdiğim seçeneklerin bana ne zaman vurduğunu görelim. Herhangi bir seçenek yoksa mutlaka bir onay istemi olacaktır.
Evet, onay yok. Seçenek yok. Daha fazla kullanıcı yok.
Bu yüzden, Bay Solaris Sysadmin'e gittim ve çaresiz bir şekilde, "Bu kutuyu desteklemedim" cevabını veren kasetten bir geri dönüşe ihtiyacım olduğunu söyledi.
"Uh, tekrar gel," Ben tekrarladım.
"Bu kutuyu desteklemiyorum. Yedekleme rotasyonuna ekleyeceğim şeyler listemde var ama henüz oraya gitmedim."
"Bu sunucu yaklaşık 8 aydır üretildi!" Çığlık attım.
omuz silkme, o cevapladı. "Afedersiniz."
Yıllar önce çalıştığım şirket, NT 4.0 Sunucusunun bir gecelik yedeğini çalıştıran bir müşteriye sahipti. Jaz sürücüsü (yüksek kapasiteli bir zip disk gibi).
Bir gecede planlı bir iş olarak çalışan bir toplu iş dosyası kurduk. Her sabah geçen gece diskten diski toplarlardı ve akşam bırakmadan önce sıradaki bir sonraki diski yerleştirirlerdi.
Her neyse, toplu iş dosyası böyle bir şeye benziyordu (Jaz sürücü F:).
@echo off F: deltree /y *.* xcopy <important files> F:
Her neyse, bir gece diski içeri almayı unuttular. F: sürücüsünü değiştirmek için yapılan değişiklik başarısız oldu (sürücüde disk yok) ve toplu iş dosyası çalışmaya devam etti. Toplu iş dosyasının varsayılan çalışma dizini? C :. İlk defa bir yedekleme rutini gördüm yıkmak Yedeklediği sunucu.
O gün sysadminning (ve istisna işleme) hakkında bir şeyler öğrendim.
Jim.
Not: Düzeltme mi? "deltree / y F: \ *. *".
root @ dbhost # find / -name çekirdeği -exec rm -f {} \;
Me: "İçeri giremez misin? Tamam. DB adı nedir?"
Cu: "Çekirdek."
Ben: "Ah."
Herkesin hikayelerini “genç / yeşilken” bir daha asla yapmayacakları gibi nitelendirmesini seviyorum. Kazalar en deneyimli profesyoneller için bile olabilir.
Benim en kötü anım o kadar kötüydü ki hala bu konuda düşünmeye başladım ...
Üzerinde üretim verileri olan bir SAN vardı. Şirket için kritik. "Akıl hocam", bazı disk alanlarını boşaltmak için bir bölüm uzatmaya karar verdi. Bunun nereye gittiğini görebiliyor musun? SAN yazılımının bunu üretim saatlerinde canlı olarak yapabileceğini ve hiç kimsenin fark etmeyeceğini söyledi. Alarm zilleri çalmaya başlamış olmalı, ancak dikkat çekecek derecede sessizlerdi. Hiç sorun yaşamadan "daha önce defalarca" yaptığını söyledi. Ama burada bir şey var - "Emin misin?" Şirkete yeniyken, bu adamın ne hakkında konuştuğunu bildiğine inandım. Büyük hata. İyi haber, LUN’un genişletilmiş olmasıydı. Kötü haber ise ... Windows kutusunda disk yazma hataları görmeye başladığımda kötü haberlerin olduğunu biliyordum.
Kahverengi pantolon giydiğime sevindim.
Öğle saatlerinde neden 1TB'nin neden kaybolduğunu açıklamak zorunda kaldık. Bu gerçekten çok kötü bir gündü.
Bu gerçekten iyi bir prensiptir - şüpheleriniz olduğu bir şeyi yapmadan önce, bir şeyler ters giderse yönetime açıklamayı hayal edin. Eylemlerinizi açıklamak için iyi bir cevap düşünemiyorsanız, o zaman yapmayın.
Nagios, iş saatlerinin kritik olmayan bir sunucuya bağlanamadığını söylediğinde bir sabah bize ping yaptı. Tamam, sunucu odasına git. Eski bir sunucu, '02'de satın alınmış bir Dell 1650 ve 1650'lerin donanım sorunları yaşadığını biliyorduk. PFY güç düğmesini tutar. Hiçbir şey değil. Tekrar vurun ve BMC'nin hata korumasını geçersiz kılan 'gücü açmayı' beş saniye kadar tutun, çünkü DRAC olmadan BMC kayıtlarını şasiye açmadan incelemenizin bir yolu yoktur.
Makine POST'u başlatır ve sonra tekrar ölür. Üstünde duruyorum ve "Duman kokusu alıyorum." Sunucuyu rayların üzerinden çekiyoruz ve güç kaynaklarından biri ısınıyor, bu yüzden PFY bunu çekiyor ve kutuyu kapatmak üzere. Ben "Hayır, bu güç kaynağı dumanı değil, anakart dumanı" diyorum.
Davayı tekrar açıyoruz ve yanan kokunun kaynağını aradık. Bir indüktör bobini ve bir kapasitör anakart üzerindeki voltaj regülatöründen bir şey patlatır ve her şeye erimiş bakır ve kapasitör goop püskürtülür, bir şeyler kısaltılır ve temelde büyük bir karmaşa yaratır.
Benim için en kötü yanı yanmış bir anakartın kokusu ile yanmış bir güç kaynağının arasındaki farkı tanımak için yeterli donanıma sahip olduğumu farketmekti.
Üç gün önce (ciddi olarak) bir Windows Server 2008 dosya sunucusuna Service Pack 2'yi yükleyerek bir okul sunucusuna uzaktan giriş yaptım.
Öğretmenlerin, yıl sonu rapor kartlarını bitirmek için oturum açmayacakları gece geç saatlerde yeniden başlatmayı planladım. Ben şöyle bir şey yazdım:
23:59 de "kapatma -r -t 0"
... iyi çalıştırabilirdi.
Ama sonra kendimi tahmin ettim. 'Kapatma' sözdizimi doğru muydu? Kullanım yardımı yazarak görüntülemeye çalıştım.
kapatma / saat
... ve hemen RDP bağlantımı kaybettim. Panikleme, sözdizimi için Google'a ulaştım. Hızlı bir arama, Server 2008'in kapatma programının, (tahmin edebileceğiniz gibi) makineyi hazırda bekleten bir / h anahtarını içerdiğini ortaya çıkardı.
Öğretmenler, üzerinde çalıştıkları rapor kartlarını artık açamayacakları veya kaydedemeyeceklerini bildirmek için dakikalar içinde beni aramaya başladılar. Tesis dışında ve sunucu odası kilitlendiğinden, okul müdürünü doğrudan aramalı ve makineyi tekrar açma işleminden geçmeliydim.
Bugün ev yapımı kurabiyeleri özür dilemek için herkese getirdim.
Daha önceki bir işte, şirkete giren, kalan ya da içinde kalan her bir posta parçasını günlüğe kaydeden ve arşivleyen harika bir homegrown sistemi vardı.
Tüm posta kutunuzu uçurdu mu? Sorun değil! Birinin size bir hafta / ay / yıl önce gönderdiği bir posta parçasını mı arıyorsunuz, ancak kimin gönderdiğini veya konunun ne olduğunu hatırlayamıyor musunuz? Sorun değil! Sizden Şubat ayına kadar her şeyi özel bir klasöre göndereceğiz.
Bir noktada, şirketin CEO'su için bir rakip ile iç satış görevlisi arasında gidip gelen postaları şüphe altında izlemek için ihtiyaç duyuldu. Bu yüzden her gece koştuktan sonra bir betik kuruyoruz ve önceki günden CEO’ya ilgili postaları gönderiyoruz. Sorun değil!
Yaklaşık bir ay sonra, çifte artı acil bir sorunun sözcüğü yüksek seviyeden çıktı. CEO'nun $ OTHERCOMPANY'ye gönderilen postalar listesi aracılığıyla okuduğunu görünce, bunun karşısına çıktı:
To: somebody@$OTHERCOMPANY From: CEO Subject: CEO has read your message (subject line here)
Doğal olarak, CEO önemli bir kişi ve hepsi, o Outlook'ta tüm "Gönderme Makbuzu Gönder" iletişim kutuları üzerine tıklamak için çok meşgul ve müşterisini sadece hepsini göndermek için yapılandırmıştı. İzleme filtresinin yakaladığı mesajlardan biri, bir okuma-makbuz talebi setine sahipti. Outlook'un ne yaptığını tahmin et? Kesinlikle 'gizli' izlemeyi durdurdu.
Bir sonraki görevimiz: CEO'nun o şirkete giden okundu bilgilerini okumak için posta filtresine kurallar eklemek. Evet, en kolay yoldu. :)
Ahhh, benim yaklaşık 10 yıl önce ayaklarımı ıslattığım zaman oldu. Tüm programcıların bilgisayarlarına pil yedeklemelerini takmanın mutluluğunu yaşadım. Ayrıca, yazılımın elektrik kesintisi konusunda uyarmak ve düzgün bir şekilde kapatılmasını istemişlerdir.
Bu yüzden, önce her şeyi test etmek için bilgisayarımda kurdum ve hepsinin çalıştığından emin oldum. Bu yüzden güç kablosunu çıkardım ve mesaj ekranımdan geliyor. msgstr "harici güç kaybedildi, sistem kapanışı başladı".
Ben de düşündüm, Hey hey, işe yaradı. Ancak bazı garip nedenlerden dolayı, hatırlamıyorum bile, bu mesajı bir ağ mesajı olarak göndermişti, böylece şirketteki tüm 200+ bilgisayar bu mesajı aldı, 100+ kullanıcı programcıların nerede olduğu.
Evet, kitle ucube hakkında konuş!
Bir süredir kafamı oralarda düşük tuttum!
Makine İsim servisini, I.P.'yi sıfırlamak için genellikle Solaris makinelerinde "sys-unconfig" komutunu kullanırdım. adres ve kök şifresi. Bir kullanıcı sistemi üzerindeydim ve bina kurulum sunucusuna giriş yaptım ve bir şeyi (root olarak) aradım, sonra başka bir makineye (tanımlayıcı olmayan "#" istemine girdiğimi unutmak) "sys-unconfig" komutunu çalıştırdım.
# sys-unconfig WARNING This program will unconfigure your system. It will cause it to revert to a "blank" system - it will not have a name or know about other systems or networks. This program will also halt the system. Do you want to continue (y/n) ? y Connection closed #
Bu "bağlantı kapatıldı" mesajı yavaşça paniğe dönüştü. Bu komutu çalıştırdığım sırada hangi makineye giriş yaptım.
Bunun en kötüsü, iş arkadaşlarımın bana verdiği zor zaman değildi, aynı şeyi bir ay sonra yaptım.