Ben bir FirstVDS sistem yöneticisiyim ve bu, acemi meslektaşlarıma yardım etmeye ilişkin kısa kursumun ilk giriş dersinin metnidir. Son zamanlarda sistem yönetimiyle ilgilenmeye başlayan uzmanlar da aynı birçok sorunla karşı karşıyadır. Çözümler sunmak için bu ders dizisini yazmayı üstlendim. İçindeki bazı şeyler teknik desteğin barındırılmasına özeldir, ancak genel olarak herkes için olmasa da birçokları için yararlı olabilirler. Bu yüzden ders metnini burada paylaşmak üzere uyarladım.
Pozisyonunuzun adı ne olursa olsun, önemli olan aslında yönetimde yer almanızdır. Bu nedenle bir sistem yöneticisinin yapması gerekenlerle başlayalım. Ana görevi işleri düzene koymak, düzeni sağlamak ve gelecekteki artışlara düzenli olarak hazırlanmaktır. Sistem yöneticisi olmadan sunucu karmakarışık hale gelir. Günlükler yazılmıyor veya içlerine yanlış şeyler yazılıyor, kaynaklar en iyi şekilde dağıtılmıyor, disk her türlü çöple doluyor ve sistem bu kadar kaostan yavaş yavaş ölmeye başlıyor. Sakin ol! Kişinizdeki sistem yöneticileri sorunları çözmeye ve karmaşayı ortadan kaldırmaya başlar!
Sistem Yönetiminin Temelleri
Ancak sorunları çözmeye başlamadan önce yönetimin dört ana sütununu tanımaya değer:
- Dokümantasyon
- Şablon oluşturma
- Optimizasyon
- Otomasyon
Bu temel bilgilerdir. İş akışınızı bu ilkeler üzerine kurmazsanız, etkisiz, verimsiz olacak ve genel olarak gerçek yönetime pek benzemeyecektir. Her birine ayrı ayrı bakalım.
Belgeleme
Belgeleme belgeleri okumak anlamına gelmez (ancak onsuz yapamazsınız), aynı zamanda onu korumak anlamına da gelir.
Belgeler nasıl saklanır:
- Daha önce hiç görmediğiniz yeni bir sorunla mı karşılaştınız? Ana semptomları, tanı yöntemlerini ve eliminasyon ilkelerini yazın.
- Yaygın bir soruna yeni ve şık bir çözüm buldunuz mu? Bir ay sonra yeniden keşfetmenize gerek kalmaması için bunu bir yere yazın.
- Anlamadığınız bir soruyu çözmenize yardımcı oldular mı? Ana noktaları ve kavramları yazın, kendiniz için bir diyagram çizin.
Ana fikir: Yeni şeylerde uzmanlaşırken ve uygularken kendi hafızanıza tamamen güvenmemelisiniz.
Bunu hangi formatta yapacağınız size kalmış: notların olduğu bir sistem, kişisel bir blog, bir metin dosyası, fiziksel bir not defteri olabilir. Önemli olan kayıtlarınızın aşağıdaki gereksinimleri karşılamasıdır:
- Çok uzun olmayın. Ana fikirleri, yöntemleri ve araçları vurgulayın. Bir sorunu anlamak, Linux'taki düşük düzeyli bellek tahsisi mekaniğine dalmayı gerektiriyorsa, onu öğrendiğiniz makaleyi yeniden yazmayın; ona bir bağlantı verin.
- Girişler sizin için açık olmalıdır. Eğer çizgi
race cond.lockupbu satırla anlattıklarınızı hemen anlamanıza izin vermiyor - açıklayın. İyi bir dokümantasyonun anlaşılması yarım saat sürmez. - Arama çok iyi bir özelliktir. Blog gönderileri yazıyorsanız etiket ekleyin; Fiziksel bir not defterindeyseniz, açıklamalar içeren küçük post-it'ler yapıştırın. Soruyu sıfırdan çözmeye harcayacağınız kadar zaman harcarsanız, belgede bir cevap aramaya harcarsanız, belgelemenin pek bir anlamı kalmaz.
Dokümantasyon şu şekilde görünebilir: not defterindeki ilkel notlardan (yukarıdaki resim), etiketler, arama ve olası tüm kolaylıkları içeren tam teşekküllü, çok kullanıcılı bir bilgi tabanına (aşağıda).
Aynı cevapları iki kez aramanıza gerek kalmayacak, aynı zamanda belgelemek yeni konuları öğrenmede çok yardımcı olacak (notlar!), örümcek duygunuzu geliştirecek (karmaşık bir sorunu tek bir yüzeysel bakışla teşhis etme yeteneği), ve eylemlerinize organizasyon katacaktır. Belgeler iş arkadaşlarınızın erişimine açıksa, siz orada olmadığınızda orada neyi ve nasıl biriktiğinizi anlamalarına olanak tanıyacaktır.
Şablon oluşturma
Şablon oluşturma şablonların oluşturulması ve kullanılmasıdır. Çoğu tipik sorunu çözmek için belirli bir eylem şablonu oluşturmaya değer. Çoğu sorunu teşhis etmek için standartlaştırılmış bir adım dizisi kullanılmalıdır. Bir şeyi onardığınızda/kurduğunuzda/optimize ettiğinizde, bu şeyin performansı standart kontrol listeleri kullanılarak kontrol edilmelidir.
Şablon oluşturma, iş akışınızı düzenlemenin en iyi yoludur. En yaygın sorunları çözmek için standart prosedürleri kullanarak pek çok harika şey elde edersiniz. Örneğin, kontrol listelerini kullanmak, işiniz için önemli olan tüm işlevleri teşhis etmenize ve önemsiz işlevlerin teşhisini atmanıza olanak tanır. Ve standartlaştırılmış prosedürler gereksiz fırlatmayı en aza indirecek ve hata olasılığını azaltacaktır.
İlk önemli nokta prosedürlerin ve kontrol listelerinin de belgelenmesi gerektiğidir. Yalnızca belleğe güvenirseniz, gerçekten önemli bazı kontrolleri veya işlemleri kaçırabilir ve her şeyi mahvedebilirsiniz. İkinci önemli nokta ise tüm şablon uygulamalarının durum gerektirdiği takdirde değiştirilebilir ve değiştirilmesi gerektiğidir. İdeal ve kesinlikle evrensel şablonlar yoktur. Bir sorun varsa ancak şablon kontrolünde sorun ortaya çıkmadıysa, bu sorun olmadığı anlamına gelmez. Bununla birlikte, olası olmayan bazı varsayımsal sorunları test etmeye başlamadan önce, her zaman hızlı bir şablon testi yapmakta fayda vardır.
Optimizasyon
Optimizasyon kendisi için konuşuyor. İş sürecinin zaman ve işçilik maliyetleri açısından mümkün olduğunca optimize edilmesi gerekiyor. Sayısız seçenek var: Klavye kısayollarını, kısaltmaları, normal ifadeleri ve mevcut araçları öğrenin. Bu araçların daha pratik kullanımlarını arayın. Bir komutu günde 100 kez çağırıyorsanız, onu bir klavye kısayoluna atayın. Düzenli olarak aynı sunuculara bağlanmanız gerekiyorsa, sizi oraya bağlayacak bir takma adı tek kelimeyle yazın:
Araçlar için mevcut farklı seçeneklere aşina olun; belki daha kullanışlı bir terminal istemcisi, DE, pano yöneticisi, tarayıcı, e-posta istemcisi, işletim sistemi vardır. Meslektaşlarınızın ve arkadaşlarınızın hangi araçları kullandığını öğrenin; belki de bunları bir nedenden dolayı seçiyorlar. Araçlara sahip olduğunuzda onları nasıl kullanacağınızı öğrenin: anahtarları, kısaltmaları, ipuçlarını ve püf noktalarını öğrenin.
Coreutils, vim, normal ifadeler, bash gibi standart araçlardan en iyi şekilde yararlanın. Son üçü için çok sayıda harika kılavuz ve belge var. Onların yardımıyla, "Kendimi dizüstü bilgisayarla fındık kıran bir maymun gibi hissediyorum" durumundan, "Kendime fındıkkıranı sipariş etmek için dizüstü bilgisayar kullanan bir maymunum" durumuna hızla geçebilirsiniz.
Otomasyon
Otomasyon zorlu operasyonları yorgun ellerimizden otomasyonun yorulmak bilmez ellerine aktaracağız. Aynı türden beş komutta bazı standart prosedürler gerçekleştiriliyorsa, o zaman neden tüm bu komutları tek bir dosyaya sarmıyor ve bu dosyayı indirip çalıştıran tek bir komut çağırmıyorsunuz?
Otomasyonun %80'i kendi araçlarınızı yazmak ve optimize etmektir (ve diğer %20'si de onların olması gerektiği gibi çalışmasını sağlamaya çalışır). Bu yalnızca gelişmiş bir tek satırlık veya web arayüzü ve API'ye sahip devasa, her şeye gücü yeten bir araç olabilir. Buradaki temel kriter, bir araç oluşturmanın, aracın size kazandıracağı zaman ve emekten daha fazla zaman ve çaba gerektirmemesidir. Bir daha asla ihtiyaç duymayacağınız bir komut dosyası yazmak için beş saat harcarsanız, komut dosyası olmadan çözmeniz bir veya iki saat sürecek bir görev için bu çok zayıf bir iş akışı optimizasyonudur. Yalnızca sayı, görev türü ve zaman izin veriyorsa, bir araç oluşturmak için beş saat harcayabilirsiniz; bu çoğu zaman geçerli değildir.
Otomasyon mutlaka tam teşekküllü komut dosyaları yazmak anlamına gelmez. Örneğin, bir listeden aynı türde bir grup nesne oluşturmak için ihtiyacınız olan tek şey, elle yaptığınız işi otomatik olarak yapacak, pencereler arasında geçiş yapacak, yığınla kopyala-yapıştır yapacak akıllı bir tek satırlık yazıdır.
Aslında yönetim sürecini bu dört temel üzerine kurarsanız verimliliğinizi, üretkenliğinizi ve niteliklerinizi hızla artırabilirsiniz. Bununla birlikte, bu listenin, BT'de çalışmanın neredeyse imkansız olduğu bir öğeyle daha desteklenmesi gerekiyor - kendi kendine eğitim.
Sistem yöneticisi kendi kendine eğitimi
Bu alanda biraz da olsa yetkin olabilmek için sürekli çalışmanız ve yeni şeyler öğrenmeniz gerekiyor. Bilinmeyenle yüzleşmek ve onu çözmek için en ufak bir arzunuz yoksa, çok çabuk takılıp kalırsınız. BT'de sürekli olarak her türlü yeni çözüm, teknoloji ve yöntem ortaya çıkıyor ve bunları en azından yüzeysel olarak incelemezseniz başarısızlığa giden yoldasınız. Bilgi teknolojisinin birçok alanı oldukça karmaşık ve hacimli bir temele dayanmaktadır. Örneğin ağ işletimi. Ağlar ve İnternet her yerdedir, onlarla her gün karşılaşırsınız, ancak bir kez onların arkasındaki teknolojiyi incelediğinizde, üzerinde çalışılması asla parkta yürüyüş olmayan, çok büyük ve çok karmaşık bir disiplin keşfedeceksiniz.
Bu öğeyi listeye dahil etmedim çünkü bu sadece sistem yönetimi için değil, genel olarak BT için de önemli. Doğal olarak her şeyi hemen öğrenemezsiniz; sadece fiziksel olarak yeterli zamanınız yoktur. Bu nedenle kendinizi eğitirken gerekli soyutlama seviyelerini hatırlamanız gerekir.
Her bir yardımcı programın dahili bellek yönetiminin nasıl çalıştığını ve Linux bellek yönetimiyle nasıl etkileşime girdiğini hemen öğrenmeniz gerekmez, ancak şematik olarak RAM'in ne olduğunu ve neden gerekli olduğunu bilmek iyidir. TCP ve UDP başlıklarının yapısal olarak ne kadar farklı olduğunu bilmenize gerek yok ancak protokollerin işleyişindeki temel farklılıkları anlamak iyi bir fikir olacaktır. Optikte sinyal zayıflamasının ne olduğunu öğrenmenize gerek yok, ancak gerçek kayıpların neden her zaman düğümler arasında aktarıldığını bilmek güzel olurdu. Belirli öğelerin belirli bir soyutlama düzeyinde nasıl çalıştığını bilmenin ve hiçbir soyutlama olmadığında tüm düzeyleri mutlaka anlamamanın yanlış bir tarafı yoktur (sadece delireceksiniz).
Ancak sizin alanınızda “eh, bu web sitelerini görüntülemenizi sağlayan bir şey” şeklinde soyutlama düzeyinde düşünmek pek iyi değil. Aşağıdaki dersler, bir sistem yöneticisinin daha düşük soyutlama seviyelerinde çalışırken ilgilenmesi gereken ana alanlara genel bir bakışa ayrılacaktır. İncelenen bilgi miktarını minimum düzeyde soyutlamayla sınırlamaya çalışacağım.
Sistem yönetiminin 10 emri
Böylece dört ana sütunu ve temeli öğrendik. Sorunları çözmeye başlayabilir miyiz? Henüz değil. Bunu yapmadan önce, sözde "en iyi uygulamalara" ve görgü kurallarına aşina olmanız tavsiye edilir. Onlar olmadan, muhtemelen yarardan çok zarar verirsiniz. Öyleyse başlayalım:
- Meslektaşlarımdan bazıları ilk kuralın "zarar vermemek" olduğuna inanıyor. Ama ben aynı fikirde olmama eğilimindeyim. Zarar vermemeye çalıştığınızda hiçbir şey yapamazsınız; çok fazla eylem potansiyel olarak yıkıcıdır. Bence en önemli kural şu: "yedekleme yapmak". Biraz hasar verseniz bile her zaman geri dönebilirsiniz ve her şey o kadar da kötü olmaz.
Her zaman zaman ve yer izin verdiğinde yedekleme yapmalısınız. Değiştireceğiniz ve potansiyel olarak yıkıcı bir eylem nedeniyle kaybetme riskiyle karşı karşıya olduğunuz şeyleri yedeklemeniz gerekir. Yedeklemenin bütünlüğünü ve gerekli tüm verilerin varlığını kontrol etmeniz önerilir. Diskte yer açmanız gerekmediği sürece, her şeyi kontrol ettikten sonra yedekleme hemen silinmemelidir. Eğer konum gerektiriyorsa kişisel sunucunuza yedekleyin ve bir hafta sonra silin.
- İkinci en önemli kural (benim de sıklıkla çiğnediğim) "saklama". Yedekleme yaptıysanız, iş arkadaşlarınızın onu aramasına gerek kalmaması için nerede olduğunu yazın. Bazı açık olmayan veya karmaşık eylemler yaptıysanız, bunu yazın: eve gideceksiniz ve sorun tekrarlanabilir veya başka biri için ortaya çıkabilir ve çözümünüz anahtar kelimeler kullanılarak bulunacaktır. Siz iyi bildiğiniz bir şeyi yapsanız bile meslektaşlarınız yapmayabilir.
- Üçüncü kuralın açıklanmasına gerek yok: “sonucunu bilmediğiniz, hayal etmediğiniz veya anlamadığınız bir şeyi asla yapmayın”. Ne işe yaradığını bilmiyorsanız komutları internetten kopyalamayın, önce man'i arayın ve ayrıştırın. Ne işe yaradığını anlayamıyorsanız hazır çözümleri kullanmayın. Gizlenmiş kodun yürütülmesini mutlak minimumda tutun. Eğer bunu çözecek vaktiniz yoksa, bir şeyi yanlış yapıyorsunuz demektir ve bir sonraki noktayı okumalısınız.
- "Ölçek". Yeni komut dosyaları, araçlar, tek satırlık satırlar ve komutlar, minimum düzeyde yıkıcı eylem potansiyeli varsa bile istemci makinede değil, kontrollü bir ortamda test edilmelidir. Her şeyi yedeklemiş olsanız bile (ve yapmışsınız), kesinti pek de hoş bir şey değil. Bunun için ayrı bir sunucu/sanal/chroot oluşturun ve orada test edin. Herhangi bir şey kırıldı mı? Daha sonra onu “savaşta” başlatabilirsiniz.
- "Kontrol". Kontrol etmediğiniz tüm işlemleri en aza indirin. Bir paket bağımlılık eğrisi sistemin yarısını aşağıya sürükleyebilir ve yum kaldırma için ayarlanan -y bayrağı size sistem kurtarma becerilerinizi sıfırdan uygulama fırsatı verir. Eylemin kontrolsüz alternatifleri yoksa bir sonraki nokta hazır bir yedeklemedir.
- "Kontrol etmek". Eylemlerinizin sonuçlarını ve bir yedeğe geri dönmeniz gerekip gerekmediğini kontrol edin. Sorunun gerçekten çözülüp çözülmediğini kontrol edin. Hatanın tekrarlanıp tekrarlanmadığını ve hangi koşullar altında oluştuğunu kontrol edin. Eylemlerinizle neleri kırabileceğinizi kontrol edin. Yaptığımız işe güvenmek ama asla kontrol etmemek gereksizdir.
- "İletişim". Sorunu çözemezseniz meslektaşlarınıza bu durumla karşılaşıp karşılaşmadıklarını sorun. Tartışmalı bir kararı uygulamak istiyorsanız meslektaşlarınızın fikrini öğrenin. Belki daha iyi bir çözüm sunarlar. Eylemlerinizden emin değilseniz bunları meslektaşlarınızla tartışın. Bu sizin uzmanlık alanınız olsa bile duruma yeni bir bakış birçok şeyi açıklığa kavuşturabilir. Kendi cehaletinizden utanmayın. Aptalca bir soru sorup aptal gibi görünüp cevap almak, soruyu sormamak, cevap alamamak ve sonunda aptal durumuna düşmekten daha iyidir.
- “Mantıksız bir şekilde yardımı reddetmeyin”. Bu nokta bir öncekinin tam tersidir. Aptalca bir soru sorulursa açıklığa kavuşturun ve açıklayın. İmkansızı istiyorlar; imkansız olduğunu ve nedenini açıklayın, alternatifler sunun. Zamanınız yoksa (gerçekten zamanınız yok, arzunuz yok) - acil bir sorunuz olduğunu, çok işiniz olduğunu, ancak bunu daha sonra çözeceğinizi söyleyin. Meslektaşlarınızın acil görevleri yoksa, onlarla iletişime geçmeyi ve soruyu başkasına devretmeyi teklif edin.
- "Geri bildirimde bulunun". Meslektaşlarınızdan biri yeni bir teknik veya yeni bir senaryo kullanmaya mı başladı ve bu kararın olumsuz sonuçlarıyla mı karşılaşıyorsunuz? Onu rapor et. Belki de sorun üç satırlık kodla veya beş dakikalık teknik iyileştirmeyle çözülebilir. Yazılımınızda bir hatayla mı karşılaştınız? Bir hata bildirin. Tekrarlanabilirse veya çoğaltılması gerekmiyorsa büyük olasılıkla düzeltilecektir. Dileklerinizi, önerilerinizi ve yapıcı eleştirilerinizi dile getirin ve konuyla ilgili görünüyorsa tartışmaya yönelik sorular sorun.
- "Geri bildirim isteyin". Hepimiz kusurluyuz, tıpkı kararlarımız gibi ve kararınızın doğruluğunu test etmenin en iyi yolu onu tartışmaya açmaktır. Bir müşteri için bir şeyi optimize ettiyseniz, ondan işi izlemesini isteyin; belki de sistemdeki darboğaz aradığınız yerde değildir. Bir yardım senaryosu yazdınız; bunu meslektaşlarınıza gösterin, belki onlar da onu geliştirmenin bir yolunu bulurlar.
Bu uygulamaları işinizde sürekli uygularsanız, sorunların çoğu artık sorun olmaktan çıkacaktır: yalnızca kendi hatalarınızın ve aksaklıklarınızın sayısını en aza indirgemekle kalmayacak, aynı zamanda hataları düzeltme fırsatına da sahip olacaksınız ( yedekleme biçimi ve size yedeklemenizi önerecek meslektaşlarınız). Dahası - yalnızca bildiğimiz gibi şeytanın yattığı teknik detaylar.
Zamanınızın %50'sinden fazlasında çalışmak zorunda kalacağınız ana araçlar grep ve vim'dir. Daha basit ne olabilir? Metin arama ve metin düzenleme. Ancak hem grep hem de vim, metni verimli bir şekilde aramanıza ve düzenlemenize olanak tanıyan güçlü çoklu araçlardır. Bazı Windows not defterleri bir satırı yazmanıza/silmenize izin veriyorsa, vim'de metinle hemen hemen her şeyi yapabilirsiniz. Bana inanmıyorsanız terminalden vimtutor komutunu çağırın ve öğrenmeye başlayın. Grep'in ana gücü düzenli ifadelerdedir. Evet, aracın kendisi arama koşullarını ayarlamanıza ve verileri oldukça esnek bir şekilde çıkarmanıza olanak tanır, ancak RegExp olmadan bunun pek bir anlamı yoktur. Ve normal ifadeleri bilmeniz gerekiyor! En azından temel düzeyde. Başlangıç olarak şuraya bakmanızı tavsiye ederim düzenli ifadelerin temellerini ve bunların grep ile birlikte kullanımını kapsar. Ah evet, bunları vim ile birleştirdiğinizde, 18'den fazla simgeyle etiketlemeniz gereken metinlerle bir şeyler yapma konusunda ULTIMATE POWER yeteneğine sahip olursunuz.
Geriye kalan %50'nin %40'ı coreutils araç setinden geliyor. Coreutils için şu adresteki listeye bakabilirsiniz: ve listenin tamamına ilişkin kılavuz web sitesinde yer almaktadır . Bu setin kapsamına girmeyenler yardımcı programlardır . Tüm anahtarları ezberlemek zorunda değilsiniz, ancak en azından temel araçların neler yapabileceğini kabaca bilmek yararlı olacaktır. Tekerleği koltuk değnekleriyle yeniden icat etmenize gerek yok. Bir şekilde bazı hizmetlerden gelen çıktıdaki satır sonlarını boşluklarla değiştirmem gerekiyordu ve hasta beynim şöyle bir yapı doğurdu: sed ':a;N;$!ba;s/n/ /g', bir meslektaşım gelip beni bir süpürgeyle konsoldan uzaklaştırdı ve ardından sorunu yazarak çözdü tr 'n' ' '.
Her bir aracın ne yaptığını ve en sık kullanılan komutların anahtarlarını hatırlamanızı tavsiye ederim; geri kalan her şey için insan vardır. Herhangi bir şüpheniz varsa, adamı aramaktan çekinmeyin. Ve adamın kendisini okuduğunuzdan emin olun; bulacağınız şeyler hakkında önemli bilgiler içerir.
Bu araçları bilerek pratikte karşılaşacağınız sorunların önemli bir bölümünü etkili bir şekilde çözebileceksiniz. Aşağıdaki derslerde, bu araçların ne zaman kullanılacağına ve bunların altında yatan hizmet ve uygulamalara yönelik çerçevelere bakacağız.
İlkVDS sistem yöneticisi Kirill Tsvetkov yanınızdaydı.
Kaynak: habr.com