چرا مهندسان به نظارت بر برنامه ها اهمیت نمی دهند؟

جمعه همگی مبارک! دوستان، امروز سری انتشارات اختصاص داده شده به دوره را ادامه می دهیم "روش ها و ابزارهای DevOps"، زیرا کلاس های گروه جدید دوره از اواخر هفته آینده شروع می شود. بنابراین، بیایید شروع کنیم!

نظارت است تنها. این یک واقعیت شناخته شده است. Nagios را بالا بیاورید، NRPE را روی سیستم راه دور اجرا کنید، Nagios را روی پورت NRPE TCP 5666 پیکربندی کنید و نظارت دارید.

آنقدر آسان است که جالب نیست. اکنون معیارهای اولیه برای زمان CPU، زیرسیستم دیسک، RAM را دارید که به طور پیش‌فرض برای Nagios و NRPE ارائه شده است. اما این در واقع "نظارت" نیست. این تازه شروع کار است.

(معمولاً PNP4Nagios، RRDtool و Thruk را نصب می‌کنند، اعلان‌ها را در Slack تنظیم می‌کنند و مستقیماً به nagiosexchange می‌روند، اما فعلاً آن را کنار بگذاریم).

نظارت خوب در واقع بسیار پیچیده است، شما واقعاً نیاز دارید که داخلی برنامه ای را که نظارت می کنید بدانید.

آیا نظارت مشکل است؟

هر سروری، خواه لینوکس یا ویندوز باشد، بنا به تعریف هدف خاصی را دنبال می کند. آپاچی، سامبا، تامکت، ذخیره سازی فایل، LDAP - همه این خدمات از یک یا چند جنبه کم و بیش منحصر به فرد هستند. هر کدام عملکرد خاص خود را دارند، ویژگی های خاص خود را دارند. راه‌های مختلفی برای دریافت معیارها، KPI (شاخص‌های کلیدی عملکرد)، وجود دارد که وقتی سرور تحت بار است برای شما جالب است.

نویسنده عکس لوک شطرنج بر می Unsplash

(کاش داشبوردهایم آبی نئون بود - رویایی آه می کشید -... هوم...)

هر نرم افزاری که خدمات ارائه می دهد باید مکانیزمی برای جمع آوری معیارها داشته باشد. آپاچی یک ماژول دارد mod-status، صفحه وضعیت سرور را نمایش می دهد. Nginx دارای - stub_status. Tomcat دارای JMX یا برنامه های وب سفارشی است که معیارهای کلیدی را نشان می دهد. MySQL دارای دستور "show global status" و غیره است.
پس چرا توسعه دهندگان مکانیسم های مشابهی را در برنامه هایی که ایجاد می کنند ایجاد نمی کنند؟

آیا فقط توسعه دهندگان این کار را انجام می دهند؟

سطح خاصی از بی تفاوتی نسبت به تعبیه معیارها به توسعه دهندگان محدود نمی شود. من در شرکت‌هایی کار می‌کردم که آنها برنامه‌هایی را با استفاده از Tomcat توسعه می‌دادند و هیچ یک از معیارهای خود، هیچ گزارش فعالیت خدمات را ارائه نمی‌دادند، به جز گزارش‌های خطای عمومی Tomcat. برخی از توسعه‌دهندگان گزارش‌های زیادی تولید می‌کنند که برای مدیر سیستم که به اندازه کافی بدشانس است آنها را در ساعت 3:15 بامداد بخواند، معنی ندارد.

نویسنده عکس تیم گوا بر می Unsplash

مهندسان سیستمی که امکان عرضه چنین محصولاتی را فراهم می کنند نیز باید مسئولیت این وضعیت را بر عهده بگیرند. تعداد کمی از مهندسان سیستم زمان یا دقت لازم را برای استخراج معیارهای معنی‌دار از لاگ‌ها دارند، بدون اینکه زمینه آن معیارها و توانایی تفسیر آنها در پرتو فعالیت برنامه‌ها وجود داشته باشد. برخی نمی دانند که چگونه می توانند از آن سود ببرند، به جز شاخص های "در حال حاضر (یا به زودی چیزی اشتباه خواهد شد)".

تغییر در تفکر در مورد نیاز به معیارها نه تنها در بین توسعه دهندگان، بلکه در میان مهندسان سیستم نیز باید رخ دهد.

برای هر مهندس سیستمی که نیاز دارد نه تنها به رویدادهای مهم پاسخ دهد، بلکه از عدم وقوع آنها نیز اطمینان حاصل کند، فقدان معیارها معمولاً مانعی برای انجام این کار است.

با این حال، مهندسان سیستم معمولاً برای کسب درآمد برای شرکت خود، کد را سرهم نمی کنند. آنها به توسعه دهندگان پیشرو نیاز دارند که اهمیت مسئولیت مهندس سیستم در شناسایی مشکلات، افزایش آگاهی از مسائل عملکرد و موارد مشابه را درک کنند.

این چیزی را توسعه می دهد

ذهنیت devops هم افزایی بین تفکر توسعه (dev) و عملیات (ops) را توصیف می کند. هر شرکتی که ادعا می کند "انجام devops" را انجام می دهد باید:

1. گفتن چیزهایی که احتمالا نمی دانند (اشاره به میم The Princess Bride - "من فکر نمی کنم معنی آن چیزی باشد که شما فکر می کنید!")
2. نگرش بهبود مستمر محصول را تشویق کنید.

اگر ندانید در حال حاضر چگونه کار می کند، نمی توانید یک محصول را بهبود ببخشید و بدانید که بهبود یافته است. اگر از نحوه عملکرد اجزای آن، خدماتی که به آن وابسته است، نقاط دردناک و تنگناهای اصلی آن آگاه نباشید، نمی توانید بدانید که چگونه یک محصول کار می کند.
اگر مراقب تنگناهای احتمالی نباشید، نمی‌توانید تکنیک پنج چرا را در هنگام نوشتن یک پست مرگ دنبال کنید. نمی‌توانید همه چیز را روی یک صفحه قرار دهید تا ببینید یک محصول چگونه کار می‌کند یا بدانید «عادی و شاد» چگونه به نظر می‌رسد.

شیفت چپ، چپ، گفتم لی ای-

برای من، یکی از اصول کلیدی Devops "تغییر به چپ" است. جابجایی به چپ در این زمینه به معنای تغییر امکان (بدون مسئولیت، اما فقط قابلیت ها) برای انجام کارهایی که مهندسان سیستم معمولاً به آنها اهمیت می دهند، مانند ایجاد معیارهای عملکرد، استفاده کارآمدتر از گزارش ها و غیره در سمت چپ چرخه عمر تحویل نرم افزار.

نویسنده عکس NESA توسط سازندگان بر می Unsplash

توسعه‌دهندگان نرم‌افزار باید بتوانند از ابزارهای نظارتی که شرکت برای انجام نظارت در همه اشکال، معیارها، گزارش‌ها، رابط‌های نظارتی و مهمتر از همه، استفاده می‌کند، استفاده کرده و بدانند. تماشا کنید که محصول آنها در تولید چگونه کار می کند. تا زمانی که نتوانند معیارها را ببینند و بر ظاهرشان تأثیر بگذارند، چگونه صاحب محصول آنها را در جلسه توجیهی بعدی به CTO ارائه می دهد، نمی توانید کاری کنید که توسعه دهندگان تلاش و زمان خود را صرف نظارت کنند.

خلاصه

1. اسب خود را به سمت آب هدایت کنید. به توسعه‌دهندگان نشان دهید که چقدر می‌توانند از مشکلات خود جلوگیری کنند، به آن‌ها کمک کنید KPI و معیارهای مناسب برای برنامه‌هایشان را شناسایی کنند تا فریادهای کمتری از سوی صاحب محصول که توسط CTO فریاد می‌زند، وجود داشته باشد. آنها را به آرامی و آرام به نور بیاورید. اگر جواب نداد، به آنها یا صاحب محصول رشوه بدهید، تهدید کنید و به آنها تحمیل کنید تا این معیارها را در سریع ترین زمان ممکن از برنامه ها دریافت کنند و سپس نمودارها را ترسیم کنید. این امر دشوار خواهد بود زیرا به عنوان یک اولویت در نظر گرفته نخواهد شد و نقشه راه محصول دارای بسیاری از پروژه های درآمدزا در انتظار خواهد بود. بنابراین، برای توجیه زمان و هزینه صرف شده برای نظارت بر محصول، به یک مورد تجاری نیاز دارید.
2. به مهندسان سیستم کمک کنید تا خواب خوبی داشته باشند. به آنها نشان دهید که استفاده از چک لیست «بیایید منتشر کنیم» برای هر محصولی که عرضه می شود چیز خوبی است. و اطمینان از اینکه همه برنامه‌های کاربردی در تولید با معیارها پوشانده شده‌اند، به شما کمک می‌کند شب‌ها بهتر بخوابید و به توسعه‌دهندگان اجازه می‌دهد ببینند چه مشکلی دارد و کجاست. با این حال، راه درست برای آزار و ناامیدی هر توسعه‌دهنده، مالک محصول یا مدیر ارشد فناوری، پافشاری و مقاومت است. اگر دوباره تا آخرین لحظه منتظر بمانید، این رفتار بر تاریخ عرضه هر محصولی تأثیر می‌گذارد، بنابراین دوباره به چپ تغییر مکان داده و در اسرع وقت این مسائل را وارد طرح پروژه خود کنید. در صورت لزوم، به جلسات محصول راه پیدا کنید. سبیل و نمد تقلبی بپوشید، هرگز شکست نمی خورد. نگرانی های خود را در میان بگذارید، مزایای واضح را نشان دهید و بشارت دهید.
3. اطمینان حاصل کنید که توسعه (dev) و عملیات (ops) معنی و پیامد معیارهای محصول در حال حرکت به منطقه قرمز را درک می کنند. Ops را به عنوان تنها نگهبان سلامت محصول رها نکنید، مطمئن شوید که توسعه دهندگان نیز درگیر آن هستند (#productsquads).
4. لاگ چیز خوبی است، اما معیارها هم همینطور. آنها را با هم ترکیب کنید و اجازه ندهید که کنده های شما در یک توپ عظیم شعله ور بی فایده تبدیل به زباله شوند. توضیح دهید و به توسعه دهندگان نشان دهید که چرا هیچ کس دیگری گزارش های آنها را نمی فهمد، به آنها نشان دهید که نگاه کردن به گزارش های بی فایده در ساعت 3:15 صبح چگونه است.

نویسنده عکس مارکو هوروات بر می Unsplash

همین. مطالب جدید هفته آینده منتشر خواهد شد. اگر مایل به کسب اطلاعات بیشتر در مورد دوره هستید، از شما دعوت می کنیم روز باز، که روز دوشنبه برگزار می شود. و اکنون به طور سنتی منتظر نظرات شما هستیم.

منبع: www.habr.com