سلام، هابر! من ده سال است که از سیستم های فناوری اطلاعات Highload پشتیبانی می کنم. من در این مقاله در مورد مشکلات راه اندازی nginx برای کار در حالت 1000+ RPS یا سایر موارد فنی نمی نویسم. من مشاهدات خود را در مورد مشکلات فرآیندهایی که در پشتیبانی و عملکرد چنین سیستم هایی ایجاد می شود به اشتراک خواهم گذاشت.
نظارت
پشتیبانی فنی منتظر نمی ماند تا درخواستی با محتوای "چرا ... سایت دوباره کار نمی کند؟" در عرض یک دقیقه پس از خرابی سایت، پشتیبانی باید از قبل مشکل را ببیند و شروع به حل آن کند. اما سایت نوک کوه یخ است. در دسترس بودن آن یکی از اولین مواردی است که نظارت می شود.
با شرایطی که کالاهای باقیمانده یک فروشگاه آنلاین دیگر از سیستم ERP وارد نمی شود چه باید کرد؟ یا سیستم CRM که تخفیف‌ها را برای مشتریان محاسبه می‌کند دیگر پاسخ نمی‌دهد؟ به نظر می رسد سایت در حال کار است. Zabbix شرطی پاسخ 200 خود را دریافت می کند. وظیفه شیفت هیچ اطلاعیه ای از مانیتورینگ دریافت نکرده و با خوشحالی مشغول تماشای اولین قسمت از فصل جدید بازی تاج و تخت است.
نظارت اغلب تنها به اندازه گیری وضعیت حافظه، رم و بار پردازنده سرور محدود می شود. اما برای کسب و کار، در دسترس بودن محصول در وب سایت بسیار مهمتر است. خرابی مشروط یک ماشین مجازی در خوشه منجر به این واقعیت می شود که ترافیک به سمت آن متوقف می شود و بار روی سرورهای دیگر افزایش می یابد. شرکت ضرر نخواهد کرد.
بنابراین، علاوه بر نظارت بر پارامترهای فنی سیستم عامل ها در سرورها، باید معیارهای تجاری را پیکربندی کنید. معیارهایی که مستقیماً بر پول تأثیر می گذارد. تعاملات مختلف با سیستم های خارجی (CRM، ERP و غیره). تعداد سفارشات برای یک دوره زمانی مشخص. مجوزهای مشتری موفق یا ناموفق و سایر معیارها.
تعامل با سیستم های خارجی
هر وب سایت یا برنامه تلفن همراه با گردش مالی سالانه بیش از یک میلیارد روبل با سیستم های خارجی تعامل دارد. شروع از CRM و ERP ذکر شده در بالا و پایان دادن به انتقال داده های فروش به یک سیستم Big Data خارجی برای تجزیه و تحلیل خریدها و ارائه محصولی به مشتری که او قطعاً خریداری خواهد کرد (در واقع نه). هر یک از این سیستم ها پشتیبانی خاص خود را دارد. و اغلب ارتباط با این سیستم ها باعث درد می شود. به خصوص زمانی که مشکل جهانی است و باید آن را در سیستم های مختلف تحلیل کنید.
برخی از سیستم ها برای مدیران خود شماره تلفن یا تلگرام ارائه می دهند. در جایی باید به مدیران نامه بنویسید یا به ردیاب های باگ این سیستم های خارجی بروید. حتی در چارچوب یک شرکت بزرگ، سیستم‌های مختلف اغلب در سیستم‌های حسابداری کاربردی متفاوت عمل می‌کنند. گاهی اوقات ردیابی وضعیت یک برنامه غیرممکن می شود. شما یک درخواست را در یک جیرا مشروط دریافت می کنید. سپس در کامنت این اولین جیرا لینک موضوع را در جیرای دیگر قرار می دهید. در Jira دوم در برنامه، شخصی در حال نوشتن یک نظر است که برای حل مشکل باید با مدیر مشروط آندری تماس بگیرید. و به همین ترتیب.
بهترین راه حل برای این مشکل ایجاد یک فضای واحد برای ارتباط است، به عنوان مثال در Slack. دعوت از همه شرکت کنندگان در فرآیند عملیات سیستم های خارجی برای پیوستن. و همچنین یک ردیاب واحد برای عدم تکرار برنامه ها. برنامه ها باید در یک مکان، از نظارت بر اعلان ها تا خروجی راه حل های اشکال در آینده، ردیابی شوند. شما خواهید گفت که این غیر واقعی است و در طول تاریخ اتفاق افتاده است که ما در یک ردیاب کار می کنیم و آنها در دیگری کار می کنند. سیستم های مختلفی ظاهر شدند، آنها تیم های مستقل فناوری اطلاعات خود را داشتند. من موافقم، و بنابراین مشکل باید از بالا در سطح CIO یا مالک محصول حل شود.
هر سیستمی که با آن تعامل دارید باید به عنوان یک سرویس با یک SLA واضح برای حل مشکلات بر اساس اولویت پشتیبانی ارائه دهد. و نه زمانی که ادمین مشروط آندری یک دقیقه برای شما دارد.
مرد تنگنا
آیا همه افراد در یک پروژه (یا محصول) فردی دارند که رفتن به تعطیلات باعث تشنج مافوق آنها شود؟ این می تواند یک مهندس devops، تحلیلگر یا توسعه دهنده باشد. از این گذشته، فقط یک مهندس devops می داند که کدام سرورها چه کانتینرهایی را نصب کرده اند، چگونه در صورت بروز مشکل کانتینر را مجددا راه اندازی کنند و به طور کلی هیچ مشکل پیچیده ای بدون او قابل حل نیست. تحلیلگر تنها کسی است که می داند مکانیسم پیچیده شما چگونه کار می کند. کدام جریان های داده به کجا می روند. تحت چه پارامترهایی از درخواست‌ها به کدام سرویس‌ها پاسخ دریافت خواهیم کرد.
چه کسی به سرعت متوجه می شود که چرا خطاها در گزارش ها وجود دارد و به سرعت یک باگ مهم در محصول را برطرف می کند؟ البته همان توسعه دهنده. دیگران نیز وجود دارند، اما به دلایلی فقط او می داند که ماژول های مختلف سیستم چگونه کار می کنند.
ریشه این مشکل عدم وجود مستندات است. از این گذشته ، اگر تمام خدمات سیستم شما شرح داده شود ، می توان بدون تحلیلگر با مشکل مقابله کرد. اگر devops چند روز از برنامه شلوغ خود را حذف کرد و همه سرورها، خدمات و دستورالعمل‌ها را برای حل مشکلات معمولی شرح داد، آنگاه مشکل در غیاب او بدون او قابل حل بود. لازم نیست در تعطیلات به سرعت آبجو خود را در ساحل تمام کنید و برای حل مشکل به دنبال وای فای باشید.
صلاحیت و مسئولیت کارکنان پشتیبانی
در پروژه های بزرگ، شرکت ها در حقوق توسعه دهندگان کوتاهی نمی کنند. آنها به دنبال میانی یا ارشد گران قیمت از پروژه های مشابه هستند. با حمایت وضعیت کمی متفاوت است. آنها به هر طریق ممکن سعی در کاهش این هزینه ها دارند. شرکت ها کارگران ارزان دیروز Enikey را استخدام می کنند و شجاعانه وارد جنگ می شوند. اگر در مورد وب سایت کارت ویزیت یک کارخانه در Zelenograd صحبت کنیم، این استراتژی امکان پذیر است.
اگر در مورد یک فروشگاه اینترنتی بزرگ صحبت می کنیم، پس هر ساعت از کار افتادگی بیش از حقوق ماهانه یک مدیر Enikey هزینه دارد. بیایید 1 میلیارد روبل گردش مالی سالانه را به عنوان نقطه شروع در نظر بگیریم. این حداقل گردش مالی هر فروشگاه آنلاین از رتبه بندی است . این مقدار را بر تعداد ساعت در سال تقسیم کنید و بیش از 100 روبل ضرر خالص دریافت کنید. و اگر ساعات شب را حساب نکنید، می توانید با خیال راحت مقدار را دو برابر کنید.
اما پول چیز اصلی نیست، درست است؟ (نه، البته نکته اصلی) زیان های اعتباری نیز وجود دارد. سقوط یک فروشگاه اینترنتی شناخته شده می تواند هم موجی از بررسی ها در شبکه های اجتماعی و هم انتشارات در رسانه های موضوعی ایجاد کند. و صحبت های دوستان در آشپزخانه به سبک "آنجا چیزی نخرید، وب سایت آنها همیشه خراب است" به هیچ وجه قابل اندازه گیری نیست.
حالا به مسئولیت در عمل من، موردی بود که مدیر وظیفه به موقع به اطلاعیه سیستم نظارت مبنی بر در دسترس نبودن سایت پاسخ نداد. در یک عصر جمعه دلپذیر تابستانی، وب سایت یک فروشگاه آنلاین معروف در مسکو بی سر و صدا بود. صبح شنبه مدیر محصول این سایت متوجه نشد که چرا سایت باز نمی شود و سکوت در چت های پشتیبانی و اطلاع رسانی فوری در Slack حاکم شد. چنین اشتباهی برای ما یک مبلغ شش رقمی تمام شد و این افسر وظیفه کارش را کرد.
مسئولیت‌پذیری مهارتی است که توسعه آن دشوار است. یا یک نفر دارد یا ندارد. بنابراین در طول مصاحبه سعی می کنم حضور آن را با سؤالات مختلفی شناسایی کنم که به طور غیرمستقیم نشان می دهد آیا فرد به مسئولیت پذیری عادت دارد یا خیر. اگر فردی پاسخ دهد که دانشگاه را به این دلیل انتخاب کرده که پدر و مادرش گفته اند یا شغلش را به دلیل اینکه همسرش گفته است درآمد کافی ندارد، عوض کرده است، بهتر است با چنین افرادی درگیر نشوید.
تعامل با تیم توسعه
هنگامی که کاربران در حین کار با یک محصول با مشکلات ساده مواجه می شوند، پشتیبانی آنها را به تنهایی حل می کند. سعی می کند مشکل را بازتولید کند، گزارش ها را تجزیه و تحلیل می کند و غیره. اما وقتی یک باگ در محصول ظاهر می شود چه باید کرد؟ در این حالت، پشتیبانی وظیفه را به توسعه دهندگان محول می کند و اینجاست که سرگرمی شروع می شود.
توسعه دهندگان دائماً بارگذاری می شوند. آنها در حال ایجاد ویژگی های جدید هستند. رفع اشکالات مربوط به فروش جالب ترین فعالیت نیست. مهلت های تکمیل سرعت بعدی نزدیک است. و سپس افراد ناخوشایند پشتیبانی می آیند و می گویند: "فورا همه چیز را رها کنید، ما مشکل داریم." اولویت چنین کارهایی حداقل است. مخصوصاً وقتی مشکل از بحرانی‌ترین حالت نیست و عملکرد اصلی سایت کار می‌کند و زمانی که مدیر انتشار با چشم‌های برآمده دور نمی‌چرخد و نمی‌نویسد: «فوراً این کار را به نسخه بعدی یا رفع فوری اضافه کنید».
مسائل با اولویت معمولی یا کم از نسخه ای به نسخه دیگر منتقل می شوند. در پاسخ به این سوال که "چه زمانی کار تکمیل می شود؟" پاسخ هایی به این سبک دریافت خواهید کرد: "متأسفم، در حال حاضر وظایف زیادی وجود دارد، از رهبران تیم خود بپرسید یا مدیر آزادسازی."
مشکلات بهره وری اولویت بیشتری نسبت به ایجاد ویژگی های جدید دارند. اگر کاربران دائماً با اشکال مواجه شوند، بررسی های بد دیری نخواهد آمد. بازگرداندن شهرت آسیب دیده دشوار است.
مسائل مربوط به تعامل بین توسعه و پشتیبانی توسط DevOps حل می شود. این مخفف اغلب به شکل یک شخص خاص استفاده می شود که به ایجاد محیط های آزمایشی برای توسعه کمک می کند، خطوط لوله CICD را ایجاد می کند و به سرعت کدهای آزمایش شده را وارد تولید می کند. DevOps رویکردی برای توسعه نرم افزار است که در آن همه شرکت کنندگان در فرآیند از نزدیک با یکدیگر تعامل دارند و به ایجاد و به روز رسانی سریع محصولات و خدمات نرم افزاری کمک می کنند. منظورم تحلیلگران، توسعه دهندگان، آزمایش کنندگان و پشتیبانی است.
در این رویکرد، پشتیبانی و توسعه بخش‌های متفاوتی با اهداف و مقاصد خاص خود نیستند. توسعه در عملیات دخیل است و بالعکس. عبارت معروف تیم های توزیع شده: "مشکل از طرف من نیست" دیگر در چت ها زیاد ظاهر نمی شود و کاربران نهایی کمی خوشحال تر می شوند.
منبع: www.habr.com