من یک مدیر سیستم FirstVDS هستم و این متن اولین سخنرانی مقدماتی از دوره کوتاه من در مورد کمک به همکاران تازه کار است. متخصصانی که اخیراً شروع به کار در مدیریت سیستم کرده اند با تعدادی از مشکلات مشابه روبرو هستند. برای ارائه راه حل، نگارش این سلسله سخنرانی ها را برعهده گرفتم. برخی موارد در آن مختص پشتیبانی فنی میزبانی است، اما به طور کلی، اگر نه برای همه، برای بسیاری، ممکن است مفید باشد. بنابراین من متن سخنرانی را برای به اشتراک گذاشتن در اینجا اقتباس کرده ام.
مهم نیست موقعیت شما چه نامیده می شود - مهم این است که در واقع شما درگیر مدیریت هستید. بنابراین، بیایید با آنچه که یک مدیر سیستم باید انجام دهد شروع می کنیم. وظیفه اصلی آن نظم بخشیدن به امور، حفظ نظم و آماده شدن برای افزایش نظم در آینده است. بدون مدیر سیستم، سرور به آشفتگی تبدیل می شود. گزارش‌ها نوشته نمی‌شوند، یا چیزهای اشتباهی در آنها نوشته می‌شود، منابع به‌طور بهینه توزیع نمی‌شوند، دیسک پر از انواع زباله‌ها می‌شود و سیستم به آرامی از این هرج و مرج شروع به مردن می‌کند. با آرامش! مدیران سیستم در شخص شما شروع به حل مشکلات و از بین بردن آشفتگی می کنند!
ارکان مدیریت سیستم
با این حال، قبل از شروع حل مشکلات، ارزش دارد که با چهار رکن اصلی مدیریت آشنا شوید:
- مستندات
- الگوسازی
- بهينه سازي
- اتوماسیون
این اصول اولیه است. اگر گردش کار خود را بر اساس این اصول بنا نکنید، بی اثر، غیرمولد خواهد بود و به طور کلی شباهت کمی به مدیریت واقعی خواهد داشت. بیایید هر کدام را جداگانه بررسی کنیم.
اسناد
اسناد به معنای خواندن اسناد نیست (اگرچه بدون آن نمی توانید انجام دهید)، بلکه به معنای حفظ آن است.
نحوه نگهداری اسناد:
- آیا با مشکل جدیدی مواجه شده اید که تا به حال ندیده اید؟ علائم اصلی، روش های تشخیص و اصول حذف را بنویسید.
- آیا راه حلی جدید و ظریف برای یک مشکل رایج ارائه کرده اید؟ آن را یادداشت کنید تا مجبور نباشید یک ماه دیگر آن را دوباره اختراع کنید.
- آیا آنها به شما کمک کردند سؤالی را که متوجه نشدید پیدا کنید؟ نکات و مفاهیم اصلی را بنویسید، نموداری برای خود بکشید.
ایده اصلی: هنگام تسلط و به کارگیری چیزهای جدید، نباید به حافظه خود کاملاً اعتماد کنید.
در چه قالبی این کار را انجام دهید به شما بستگی دارد: این می تواند یک سیستم با یادداشت ها، یک وبلاگ شخصی، یک فایل متنی، یک دفترچه یادداشت فیزیکی باشد. نکته اصلی این است که سوابق شما دارای شرایط زیر باشد:
- زیاد طولانی نکن. ایده ها، روش ها و ابزارهای اصلی را برجسته کنید. اگر درک یک مشکل مستلزم غواصی در مکانیک سطح پایین تخصیص حافظه در لینوکس است، مقاله ای را که از آن آموخته اید بازنویسی نکنید - پیوندی به آن ارائه دهید.
- ورودی ها باید برای شما واضح باشد. اگر خط
race cond.lockupبه شما اجازه نمی دهد فوراً آنچه را که با این خط توصیف کردید درک کنید - توضیح دهید. درک مستندات خوب نیم ساعت طول نمی کشد. - جستجو یک ویژگی بسیار خوب است. اگر پست های وبلاگ می نویسید، برچسب ها را اضافه کنید. اگر در یک دفترچه یادداشت فیزیکی هستید، پست های کوچکی را با توضیحات بچسبانید. اگر به اندازه‌ای که برای حل سؤال از ابتدا وقت صرف می‌کردید، برای یافتن پاسخ در آن زمان صرف کنید، مستندسازی فایده‌ای ندارد.
مستندات می توانند به این شکل باشند: از یادداشت های ابتدایی در دفترچه یادداشت (تصویر بالا)، تا یک پایگاه دانش کامل چند کاربره با برچسب ها، جستجو و همه امکانات ممکن (در زیر).
نه تنها مجبور نیستید دوبار به دنبال پاسخ های یکسان باشید، بلکه مستندسازی کمک بزرگی در یادگیری موضوعات جدید (یادداشت ها!)، حس عنکبوتی شما (توانایی تشخیص یک مشکل پیچیده با یک نگاه سطحی) خواهد بود. و سازماندهی را به اقدامات شما اضافه خواهد کرد. اگر مدارک در دسترس همکاران شما باشد، به آنها این امکان را می دهد که بفهمند وقتی شما آنجا نیستید چه چیزی و چگونه در آنجا انباشته شده اید.
الگوسازی
الگوسازی ایجاد و استفاده از قالب ها است. برای حل اکثر مسائل معمولی، ارزش ایجاد یک الگوی اقدام خاص را دارد. برای تشخیص بیشتر مشکلات باید از یک توالی استاندارد از مراحل استفاده شود. وقتی چیزی را تعمیر/نصب/بهینه‌سازی کردید، عملکرد این مورد باید با استفاده از چک لیست‌های استاندارد بررسی شود.
الگوسازی بهترین راه برای سازماندهی گردش کار شماست. با استفاده از روش های استاندارد برای حل رایج ترین مشکلات، چیزهای جالب زیادی به دست می آورید. به عنوان مثال، استفاده از چک لیست ها به شما این امکان را می دهد که همه عملکردهایی را که برای کار شما مهم هستند تشخیص دهید و تشخیص عملکردهای غیر مهم را کنار بگذارید. و روش های استاندارد پرتاب غیر ضروری را به حداقل می رساند و احتمال خطا را کاهش می دهد.
اولین نکته مهم این است که رویه ها و چک لیست ها نیز باید مستند باشند. اگر فقط به حافظه تکیه کنید، می توانید یک بررسی یا عملیات بسیار مهم را از دست بدهید و همه چیز را خراب کنید. دومین نکته مهم این است که در صورت اقتضای شرایط، تمامی شیوه های الگو می توانند و باید اصلاح شوند. هیچ قالب ایده آل و کاملاً جهانی وجود ندارد. اگر مشکلی وجود دارد، اما بررسی الگو آن را نشان نداد، این به این معنی نیست که مشکلی وجود ندارد. با این حال، قبل از شروع آزمایش برخی از مشکلات فرضی بعید، همیشه ارزش دارد ابتدا یک آزمایش قالب سریع انجام دهید.
بهینه سازی
بهینه سازی برای خودش صحبت می کند فرآیند کار باید تا حد امکان از نظر زمان و هزینه های نیروی کار بهینه شود. گزینه های بی شماری وجود دارد: یادگیری میانبرهای صفحه کلید، اختصارات، عبارات منظم، ابزارهای موجود. به دنبال استفاده های عملی تر از این ابزار باشید. اگر یک فرمان را 100 بار در روز فراخوانی می کنید، آن را به میانبر صفحه کلید اختصاص دهید. اگر نیاز دارید که به طور منظم به همان سرورها متصل شوید، یک نام مستعار در یک کلمه بنویسید که شما را به آنجا متصل کند:
با گزینه های مختلف موجود برای ابزارها آشنا شوید - شاید یک مشتری ترمینال راحت تر، DE، مدیر کلیپ بورد، مرورگر، سرویس گیرنده ایمیل، سیستم عامل وجود داشته باشد. دریابید که همکاران و دوستان شما از چه ابزارهایی استفاده می کنند - شاید آنها آنها را به دلیلی انتخاب می کنند. هنگامی که ابزارها را در اختیار دارید، نحوه استفاده از آنها را بیاموزید: کلیدها، اختصارات، نکات و ترفندها را یاد بگیرید.
استفاده بهینه از ابزارهای استاندارد - coreutils، vim، عبارات منظم، bash. برای سه مورد آخر تعداد زیادی کتابچه راهنمای و مستندات فوق العاده وجود دارد. با کمک آنها، می توانید به سرعت از حالت "احساس می کنم میمونی هستم که با لپ تاپ آجیل می شکند" به "من میمونی هستم که از لپ تاپ استفاده می کند تا برای خودم آجیل شکن سفارش دهد" بروید.
اتوماسیون
اتوماسیون عملیات دشوار را از دستان خسته ما به دستان خستگی ناپذیر اتوماسیون منتقل می کند. اگر یک روش استاندارد در پنج دستور از یک نوع انجام می شود، پس چرا همه این دستورات را در یک فایل قرار نمی دهیم و یک فرمان را که این فایل را دانلود و اجرا می کند فراخوانی نکنیم؟
خود اتوماسیون 80% نوشتن و بهینه سازی ابزارهای شماست (و 20% دیگر تلاش می کند تا آنها را همانطور که باید کار کنند). این می تواند فقط یک خط پیشرفته پیشرفته یا یک ابزار همه کاره عظیم با رابط وب و API باشد. معیار اصلی در اینجا این است که ایجاد یک ابزار نباید بیشتر از زمان و تلاشی که ابزار شما را صرفه‌جویی می‌کند، زمان و تلاشی صرف کند. اگر پنج ساعت را صرف نوشتن یک اسکریپت کنید که دیگر هرگز به آن نیاز نخواهید داشت، برای کاری که حل آن بدون اسکریپت یک یا دو ساعت زمان می برد، این یک بهینه سازی گردش کار بسیار ضعیف است. فقط در صورتی می توانید پنج ساعت برای ایجاد یک ابزار وقت بگذارید که تعداد، نوع کارها و زمان آن را اجازه دهد، که اغلب اینطور نیست.
اتوماسیون لزوما به معنای نوشتن اسکریپت های کامل نیست. به عنوان مثال، برای ایجاد دسته‌ای از اشیاء از همان نوع از یک لیست، تنها چیزی که نیاز دارید یک تک خط هوشمند است که به‌طور خودکار کاری را که با دست انجام می‌دهید، جابه‌جایی بین پنجره‌ها، با انبوهی از کپی پیست انجام می‌دهد.
در واقع، اگر فرآیند مدیریت را بر روی این چهار ستون بنا کنید، می توانید به سرعت کارایی، بهره وری و شایستگی های خود را افزایش دهید. با این حال ، این لیست باید با یک مورد دیگر تکمیل شود که بدون آن کار در فناوری اطلاعات تقریباً غیرممکن است - خودآموزی.
خودآموزی مدیر سیستم
برای اینکه در این زمینه حتی کمی شایستگی داشته باشید، باید مدام مطالعه کنید و چیزهای جدید یاد بگیرید. اگر کوچکترین تمایلی به رویارویی با ناشناخته ها و کشف آن نداشته باشید، خیلی زود گیر می کنید. انواع راه حل ها، فناوری ها و روش های جدید به طور مداوم در فناوری اطلاعات ظاهر می شوند و اگر حداقل به صورت سطحی آنها را مطالعه نکنید، در مسیر شکست قرار گرفته اید. بسیاری از حوزه های فناوری اطلاعات بر پایه های بسیار پیچیده و گسترده ای قرار دارند. به عنوان مثال، عملیات شبکه. شبکه‌ها و اینترنت همه جا هستند، شما هر روز با آنها روبرو می‌شوید، اما وقتی به فناوری پشت آنها بپردازید، رشته‌ای عظیم و بسیار پیچیده را کشف خواهید کرد که مطالعه آن هرگز پیاده‌روی در پارک نیست.
من این مورد را در لیست قرار ندادم زیرا به طور کلی برای فناوری اطلاعات و نه فقط برای مدیریت سیستم کلیدی است. به طور طبیعی، شما نمی توانید بلافاصله همه چیز را یاد بگیرید - به سادگی از نظر فیزیکی زمان کافی ندارید. بنابراین، هنگام آموزش خود، باید سطوح لازم انتزاع را به خاطر بسپارید.
لازم نیست فوراً یاد بگیرید که مدیریت حافظه داخلی هر ابزار جداگانه چگونه کار می کند و چگونه با مدیریت حافظه لینوکس تعامل دارد، اما خوب است بدانید که RAM از نظر شماتیک چیست و چرا به آن نیاز است. لازم نیست بدانید که سرفصل‌های TCP و UDP چگونه از نظر ساختاری متفاوت هستند، اما بهتر است تفاوت‌های اساسی در نحوه عملکرد پروتکل‌ها را درک کنید. نیازی نیست که بدانید تضعیف سیگنال در اپتیک چیست، اما خوب است بدانید که چرا تلفات واقعی همیشه در سراسر گره ها به ارث می رسد. هیچ اشکالی ندارد که بدانید عناصر خاصی در سطح معینی از انتزاع چگونه کار می کنند و لزوماً همه سطوح را درک نکنید در حالی که اصلاً انتزاعی وجود ندارد (شما دیوانه خواهید شد).
با این حال، در زمینه شما، فکر کردن در سطح انتزاع "خوب، این چیزی است که به شما امکان نمایش وب سایت ها را می دهد" خیلی خوب نیست. سخنرانی‌های زیر به مروری بر زمینه‌های اصلی که یک مدیر سیستم باید هنگام کار در سطوح پایین‌تر انتزاع با آنها سر و کار داشته باشد، اختصاص خواهد یافت. من سعی خواهم کرد میزان دانش بررسی شده را به حداقل سطح انتزاع محدود کنم.
10 فرمان مدیریت سیستم
بنابراین، ما چهار رکن اصلی و پایه را یاد گرفتیم. آیا می توانیم شروع به حل مشکلات کنیم؟ نه هنوز. قبل از انجام این کار، توصیه می شود خود را با به اصطلاح "بهترین شیوه ها" و قوانین رفتار خوب آشنا کنید. بدون آنها، شما به احتمال زیاد ضرر بیشتری نسبت به سود خواهید داشت. بنابراین، بیایید شروع کنیم:
- برخی از همکاران من بر این باورند که اولین قانون "آسیب نرسانید" است. اما من تمایل به مخالفت دارم. وقتی سعی می کنید آسیبی نرسانید، نمی توانید کاری انجام دهید - اقدامات بیش از حد به طور بالقوه مخرب هستند. من فکر می کنم مهمترین قانون این است - "یک نسخه پشتیبان تهیه کنید". حتی اگر آسیبی وارد کنید، همیشه می توانید عقب نشینی کنید و همه چیز آنقدر بد نخواهد بود.
همیشه باید در زمانی که زمان و مکان اجازه می دهد از آن نسخه پشتیبان تهیه کنید. شما باید از چیزهایی که تغییر خواهید داد و به دلیل یک اقدام بالقوه مخرب در خطر از دست دادن آن هستید، نسخه پشتیبان تهیه کنید. توصیه می شود نسخه پشتیبان را از نظر یکپارچگی و وجود تمام داده های لازم بررسی کنید. پس از بررسی همه چیز، نسخه پشتیبان نباید بلافاصله حذف شود، مگر اینکه نیاز به آزاد کردن فضای دیسک داشته باشید. اگر موقعیت مکانی به آن نیاز دارد، از آن در سرور شخصی خود نسخه پشتیبان تهیه کنید و پس از یک هفته آن را حذف کنید.
- دومین قانون مهم (که خود من اغلب آن را زیر پا می گذارم) این است "پنهان نکن". اگر یک نسخه پشتیبان تهیه کردید، جایی را بنویسید تا همکارانتان مجبور به جستجوی آن نباشند. اگر اقدامات غیر آشکار یا پیچیده ای انجام دادید، آن را یادداشت کنید: به خانه می روید و ممکن است مشکل تکرار شود یا برای شخص دیگری پیش بیاید و راه حل شما با استفاده از کلمات کلیدی پیدا می شود. حتی اگر کاری را انجام دهید که به خوبی می دانید، ممکن است همکارانتان نتوانند.
- قانون سوم نیازی به توضیح ندارد: "هرگز کاری را انجام نده که عواقب آن را نمی دانی، تصور نمی کنی یا نمی فهمی". دستورات را از اینترنت کپی نکنید اگر نمی دانید چه کار می کنند، ابتدا با man تماس بگیرید و آنها را تجزیه کنید. اگر نمی توانید از راه حل های آماده استفاده کنید. اجرای کد مبهم را به حداقل مطلق نگه دارید. اگر وقت ندارید آن را بفهمید، پس کار اشتباهی انجام می دهید و باید نکته بعدی را بخوانید.
- "تست". اسکریپت‌ها، ابزارها، تک خط‌ها و دستورات جدید باید در یک محیط کنترل‌شده آزمایش شوند، نه روی ماشین کلاینت، اگر حتی حداقل پتانسیل برای اقدامات مخرب وجود داشته باشد. حتی اگر از همه چیز نسخه پشتیبان تهیه کرده باشید (و این کار را انجام دادید)، زمان از کار افتادگی جالب ترین چیز نیست. برای این کار یک سرور/مجازی/کروت جداگانه ایجاد کنید و آنجا تست کنید. آیا چیزی شکسته است؟ سپس می توانید آن را در "مبارزه" راه اندازی کنید.
- "کنترل". تمام عملیاتی را که کنترل نمی کنید به حداقل برسانید. یک منحنی وابستگی بسته می‌تواند نیمی از سیستم را به پایین بکشد، و پرچم -y که برای حذف yum تنظیم شده است به شما این فرصت را می‌دهد تا مهارت‌های بازیابی سیستم خود را از ابتدا تمرین کنید. اگر عمل هیچ جایگزین کنترل نشده ای نداشته باشد، نکته بعدی یک نسخه پشتیبان آماده است.
- "بررسی". عواقب اقدامات خود را بررسی کنید و اینکه آیا نیاز به بازگشت به نسخه پشتیبان دارید یا خیر. بررسی کنید که آیا مشکل واقعا حل شده است یا خیر. بررسی کنید که آیا خطا تکرار شده است و تحت چه شرایطی. بررسی کنید که چه چیزی را می توانید با اقدامات خود شکست دهید. اعتماد به کارمان ضروری نیست، اما هرگز بررسی نکنیم.
- "برقراری ارتباط". اگر نمی توانید مشکل را حل کنید، از همکاران خود بپرسید که آیا با این مشکل مواجه شده اند یا خیر. اگر می خواهید تصمیمی بحث برانگیز را اعمال کنید، نظر همکاران خود را جویا شوید. شاید راه حل بهتری ارائه دهند. اگر به اقدامات خود اطمینان ندارید، آنها را با همکاران خود در میان بگذارید. حتی اگر این حوزه تخصص شما باشد، نگاهی تازه به این وضعیت می تواند خیلی چیزها را روشن کند. از نادانی خود خجالت نکش. بهتر است یک سوال احمقانه بپرسید، شبیه یک احمق به نظر برسید و جواب بگیرید، تا اینکه سوال نپرسید، جواب نگیرید و در نهایت احمق شوید.
- "کمک بی دلیل را رد نکنید". این نقطه برعکس مورد قبلی است. اگر سوال احمقانه ای از شما پرسیده شد، توضیح دهید و توضیح دهید. آنها غیرممکن را می خواهند - توضیح دهید که غیرممکن است و چرا، جایگزین هایی ارائه دهید. اگر وقت ندارید (واقعاً وقت ندارید، نه تمایل) - بگویید که یک سؤال فوری دارید، کار زیادی دارید، اما بعداً آن را مرتب خواهید کرد. اگر همکاران وظایف فوری ندارند، پیشنهاد دهید با آنها تماس بگیرید و سؤال را محول کنید.
- "بازخورد دادن". آیا یکی از همکارانتان شروع به استفاده از تکنیک یا فیلمنامه جدیدی کرده است و آیا با پیامدهای منفی این تصمیم مواجه هستید؟ آنرا گزارش کن. شاید بتوان مشکل را در سه خط کد یا پنج دقیقه اصلاح تکنیک حل کرد. آیا با مشکلی در نرم افزار خود مواجه شده اید؟ گزارش یک اشکال. اگر قابل تکرار باشد یا نیازی به تکثیر نداشته باشد، به احتمال زیاد رفع می شود. خواسته ها، پیشنهادات و انتقادات سازنده خود را بیان کنید و اگر به نظر مرتبط هستند، سؤالاتی را برای بحث مطرح کنید.
- "بازخورد بخواهید". همه ما درست مانند تصمیماتمان ناقص هستیم و بهترین راه برای آزمایش درستی تصمیم شما این است که آن را برای بحث مطرح کنید. اگر چیزی را برای مشتری بهینه کرده اید، از او بخواهید که کار را نظارت کند؛ شاید گلوگاه سیستم جایی نباشد که شما به دنبال آن بودید. شما یک اسکریپت راهنما نوشته اید - آن را به همکاران خود نشان دهید، شاید راهی برای بهبود آن پیدا کنند.
اگر دائماً این شیوه‌ها را در کار خود به کار ببرید، بیشتر مشکلات دیگر مشکل خواهند بود: شما نه تنها تعداد اشتباهات و کاوش‌های خود را به حداقل می‌رسانید، بلکه فرصت اصلاح اشتباهات را نیز خواهید داشت. فرم پشتیبان گیری و همکارانی که به شما توصیه می کنند پشتیبان تهیه کنید). علاوه بر این - فقط جزئیات فنی، که، همانطور که می دانیم، شیطان در آن نهفته است.
ابزارهای اصلی که بیش از 50 درصد مواقع باید با آنها کار کنید grep و vim هستند. چه چیزی می تواند ساده تر باشد؟ جستجوی متن و ویرایش متن. با این حال، هر دو grep و vim ابزارهای چندگانه قدرتمندی هستند که به شما امکان جستجو و ویرایش متن را به طور موثر می دهند. اگر برخی از نوت‌پدهای ویندوز به شما اجازه می‌دهند به سادگی یک خط بنویسید/حذف کنید، در vim تقریباً می‌توانید هر کاری را با متن انجام دهید. اگر باور نمی کنید، با فرمان vimtutor از ترمینال تماس بگیرید و شروع به یادگیری کنید. در مورد grep، قدرت اصلی آن در عبارات منظم است. بله، خود این ابزار به شما امکان می‌دهد شرایط جستجو و خروجی داده‌ها را کاملاً انعطاف‌پذیر تنظیم کنید، اما بدون RegExp این کار چندان منطقی نیست. و باید عبارات منظم را بدانید! حداقل در سطح پایه. برای شروع، من به شما توصیه می کنم به این نگاه کنید ، اصول عبارات منظم و استفاده از آنها را در ارتباط با grep پوشش می دهد. اوه بله، وقتی آنها را با vim ترکیب می‌کنید، توانایی نهایی برای انجام کارهایی با متن را دریافت می‌کنید که باید آنها را با نمادهای 18+ برچسب بزنید.
از 50٪ باقی مانده، 40٪ از جعبه ابزار coreutils می آید. برای coreutils می توانید به لیست در نگاه کنید و راهنمای کل لیست در وب سایت موجود است . آنچه در این مجموعه پوشش داده نمی شود در خدمات شهری است . لازم نیست تمام کلیدها را از روی قلب یاد بگیرید، اما این مفید است که حداقل بدانید که ابزارهای اولیه چه کاری می توانند انجام دهند. لازم نیست چرخ را از عصا دوباره اختراع کنید. من به نحوی نیاز داشتم که شکستگی های خط را با فاصله های موجود در خروجی برخی ابزارها جایگزین کنم و مغز بیمار من ساختاری مانند sed ':a;N;$!ba;s/n/ /g'یکی از همکاران آمد و با جارو مرا از کنسول دور کرد و بعد با نوشتن مشکل را حل کرد. tr 'n' ' '.
من به شما توصیه می کنم به یاد داشته باشید که هر ابزار فردی چه می کند و کلیدهای دستورات پرکاربرد را به خاطر بسپارید؛ برای هر چیز دیگری انسان وجود دارد. در صورت داشتن شک و تردید با مرد تماس بگیرید. و حتماً خود مرد را بخوانید - حاوی اطلاعات مهمی در مورد آنچه خواهید یافت.
با دانستن این ابزارها قادر خواهید بود بخش قابل توجهی از مشکلاتی را که در عمل با آنها مواجه خواهید شد به طور موثر حل کنید. در سخنرانی‌های بعدی، به زمان استفاده از این ابزارها و چارچوب‌های مربوط به سرویس‌ها و برنامه‌های کاربردی که برای آنها اعمال می‌شوند، خواهیم پرداخت.
مدیر سیستم FirstVDS، Kirill Tsvetkov با شما بود.
منبع: www.habr.com