در مرحله تشکیل تیم های محصول به فکر ایجاد سیستم نظارتی بودیم. مشخص شد که تجارت ما - استثمار - در این تیم ها قرار نمی گیرد. چرا اینطور است؟
واقعیت این است که همه تیم‌های ما حول سیستم‌های اطلاعاتی، میکروسرویس‌ها و جبهه‌ها ساخته شده‌اند، بنابراین تیم‌ها سلامت کلی کل سیستم را به عنوان یک کل نمی‌بینند. به عنوان مثال، آنها ممکن است ندانند که چگونه قسمت کوچکی در قسمت عمقی روی قسمت جلویی تأثیر می گذارد. دامنه علاقه آنها محدود به سیستم هایی است که سیستم آنها با آنها یکپارچه شده است. اگر یک تیم و سرویس A تقریباً هیچ ارتباطی با سرویس B نداشته باشند، چنین سرویسی تقریباً برای تیم نامرئی است.
تیم ما به نوبه خود با سیستم هایی کار می کند که به شدت با یکدیگر ادغام شده اند: ارتباطات زیادی بین آنها وجود دارد، این یک زیرساخت بسیار بزرگ است. و عملکرد فروشگاه آنلاین به همه این سیستم ها بستگی دارد (که ما تعداد زیادی از آنها را داریم).
بنابراین معلوم می شود که دپارتمان ما به هیچ تیمی تعلق ندارد، بلکه کمی در کنار آن قرار دارد. در کل این داستان، وظیفه ما این است که به طور جامع درک کنیم که سیستم های اطلاعاتی چگونه کار می کنند، عملکرد آنها، ادغام ها، نرم افزار، شبکه، سخت افزار و نحوه اتصال همه اینها به یکدیگر.
پلتفرمی که فروشگاه های آنلاین ما در آن فعالیت می کنند به شرح زیر است:
- جلو
- دفتر وسطی
- دفتر تماس
هر چقدر هم که بخواهیم، این اتفاق نمی افتد که همه سیستم ها بدون مشکل و بدون نقص کار کنند. نکته، دوباره، تعداد سیستم‌ها و ادغام‌ها است - با چیزی شبیه به ما، با وجود کیفیت آزمایش، برخی از حوادث اجتناب‌ناپذیر هستند. علاوه بر این، هم در یک سیستم جداگانه و هم از نظر یکپارچگی آنها. و شما باید وضعیت کل پلتفرم را به طور جامع رصد کنید، نه فقط هر بخش جداگانه ای از آن.
در حالت ایده آل، نظارت بر سلامت در سطح پلت فرم باید خودکار باشد. و ما به نظارت به عنوان بخشی اجتناب ناپذیر از این فرآیند رسیدیم. در ابتدا، فقط برای بخش خط مقدم ساخته شده بود، در حالی که متخصصان شبکه، مدیران نرم افزار و سخت افزار سیستم های نظارت لایه به لایه خود را داشتند و دارند. همه این افراد فقط در سطح خودشان نظارت را دنبال می کردند؛ هیچکس هم درک جامعی نداشت.
به عنوان مثال، اگر یک ماشین مجازی از کار بیفتد، در بیشتر موارد فقط مدیر مسئول سخت افزار و ماشین مجازی از آن مطلع است. در چنین مواردی، تیم خط مقدم واقعیت سقوط برنامه را دید، اما اطلاعاتی در مورد از کار افتادن ماشین مجازی نداشت. و مدیر می تواند بداند مشتری کیست و ایده ای تقریبی از آنچه در حال حاضر روی این ماشین مجازی در حال اجرا است داشته باشد، مشروط بر اینکه این یک نوع پروژه بزرگ باشد. او به احتمال زیاد از بچه های کوچک خبر ندارد. در هر صورت، مدیر باید به مالک مراجعه کند و بپرسد چه چیزی در این دستگاه وجود دارد، چه چیزی باید بازیابی شود و چه چیزی باید تغییر کند. و اگر چیزی واقعاً جدی خراب شد، آنها شروع به دویدن در دایره‌ها کردند - زیرا هیچکس سیستم را به‌عنوان یک کل نمی‌دید.
در نهایت، چنین داستان‌های متفاوتی بر کل صفحه اصلی، کاربران و عملکرد اصلی تجارت ما - فروش آنلاین - تأثیر می‌گذارد. از آنجایی که ما بخشی از یک تیم نیستیم، اما به عنوان بخشی از یک فروشگاه آنلاین درگیر عملیات تمام برنامه های تجارت الکترونیک هستیم، وظیفه ایجاد یک سیستم نظارت جامع برای پلت فرم تجارت الکترونیک را بر عهده گرفتیم.
ساختار و پشته سیستم
ما با شناسایی چندین لایه نظارتی برای سیستم های خود شروع کردیم، که در آن باید معیارها را جمع آوری کنیم. و همه اینها نیاز به ترکیب داشت، کاری که ما در مرحله اول انجام دادیم. اکنون در این مرحله، مجموعه‌ای از معیارها را با بالاترین کیفیت در تمام لایه‌های خود نهایی می‌کنیم تا بتوانیم همبستگی ایجاد کنیم و بفهمیم که چگونه سیستم‌ها بر یکدیگر تأثیر می‌گذارند.
فقدان نظارت جامع در مراحل اولیه راه‌اندازی اپلیکیشن (از زمانی که ساخت آن را شروع کردیم، زمانی که بیشتر سیستم‌ها در حال تولید بودند) به این واقعیت منجر شد که ما بدهی فنی قابل توجهی برای راه‌اندازی نظارت بر کل پلت فرم داشتیم. ما نمی‌توانستیم روی راه‌اندازی نظارت برای یک IS و انجام نظارت دقیق برای آن تمرکز کنیم، زیرا بقیه سیستم‌ها برای مدتی بدون نظارت باقی خواهند ماند. برای حل این مشکل، فهرستی از ضروری ترین معیارها برای ارزیابی وضعیت سیستم اطلاعاتی را به صورت لایه شناسایی کردیم و شروع به پیاده سازی کردیم.
بنابراین، آنها تصمیم گرفتند فیل را تکه تکه بخورند.
سیستم ما شامل موارد زیر است:
- سخت افزار؛
- سیستم عامل؛
- نرم افزار؛
- بخش های رابط کاربری در برنامه نظارت؛
- معیارهای کسب و کار؛
- برنامه های یکپارچه سازی؛
- امنیت اطلاعات؛
- شبکه های؛
- متعادل کننده ترافیک
در مرکز این سیستم خود نظارت است. برای اینکه به طور کلی وضعیت کل سیستم را درک کنید، باید بدانید که چه اتفاقی برای برنامه های کاربردی در همه این لایه ها و در کل مجموعه برنامه ها می افتد.
بنابراین، در مورد پشته.
ما از نرم افزار متن باز استفاده می کنیم. در مرکز ما Zabbix را داریم که در درجه اول از آن به عنوان یک سیستم هشدار استفاده می کنیم. همه می دانند که برای نظارت بر زیرساخت ایده آل است. این یعنی چی؟ دقیقاً آن معیارهای سطح پایینی که هر شرکتی که مرکز داده خود را حفظ می کند (و Sportmaster مراکز داده خود را دارد) دارد - دمای سرور، وضعیت حافظه، حمله، معیارهای دستگاه شبکه.
ما Zabbix را با پیام رسان تلگرام و تیم های مایکروسافت ادغام کرده ایم که به طور فعال در تیم ها استفاده می شود. Zabbix لایه شبکه واقعی، سخت افزار و برخی نرم افزارها را پوشش می دهد، اما این یک نوشدارویی نیست. ما این داده ها را از برخی خدمات دیگر غنی می کنیم. به عنوان مثال، در سطح سخت افزار، ما مستقیماً از طریق API به سیستم مجازی سازی خود متصل می شویم و داده ها را جمع آوری می کنیم.
چه چیز دیگری. علاوه بر Zabbix، ما از Prometheus استفاده می کنیم که به ما امکان می دهد معیارها را در یک برنامه محیط پویا نظارت کنیم. یعنی ما می توانیم معیارهای برنامه را از طریق یک نقطه پایانی HTTP دریافت کنیم و نگران نباشیم که کدام معیارها را در آن بارگذاری کنیم و کدام را نه. بر اساس این داده ها می توان پرس و جوهای تحلیلی را توسعه داد.
منابع داده برای لایه های دیگر، به عنوان مثال، معیارهای تجاری، به سه جزء تقسیم می شوند.
اولا، اینها سیستم های تجاری خارجی هستند، Google Analytics، ما معیارها را از سیاههها جمع آوری می کنیم. از آنها ما داده‌های مربوط به کاربران فعال، تبدیل‌ها و هر چیز دیگری را که مربوط به کسب و کار است دریافت می‌کنیم. در مرحله دوم، این یک سیستم نظارت بر رابط کاربری است. باید با جزئیات بیشتری توضیح داده شود.
روزی روزگاری ما با آزمایش دستی شروع کردیم و به تست‌های خودکار عملکرد و ادغام تبدیل شد. از این رو ما نظارت را انجام دادیم و فقط عملکرد اصلی را باقی گذاشتیم و به نشانگرهایی تکیه کردیم که تا حد امکان پایدار هستند و اغلب در طول زمان تغییر نمی کنند.
ساختار تیم جدید به این معنی است که تمام فعالیت های برنامه محدود به تیم های محصول است، بنابراین ما انجام آزمایش خالص را متوقف کردیم. در عوض، ما نظارت بر رابط کاربری را از آزمایش‌ها، نوشته‌شده در جاوا، سلنیوم و جنکینز (که به عنوان سیستمی برای راه‌اندازی و تولید گزارش استفاده می‌شود) انجام دادیم.
ما تست های زیادی داشتیم، اما در نهایت تصمیم گرفتیم به جاده اصلی برویم، متریک سطح بالا. و اگر آزمایش های خاص زیادی داشته باشیم، به روز نگه داشتن داده ها دشوار خواهد بود. هر نسخه بعدی به طور قابل توجهی کل سیستم را خراب می کند و تنها کاری که ما انجام خواهیم داد این است که آن را تعمیر کنیم. بنابراین، ما روی چیزهای بسیار اساسی تمرکز کردیم که به ندرت تغییر می کنند و فقط آنها را زیر نظر داریم.
در نهایت، ثالثاً، منبع داده یک سیستم ثبت مرکزی است. ما از Elastic Stack برای گزارش‌ها استفاده می‌کنیم، و سپس می‌توانیم این داده‌ها را به سیستم نظارت خود برای معیارهای تجاری بکشیم. علاوه بر همه اینها، ما سرویس Monitoring API خودمان را داریم که به زبان Python نوشته شده است، که هر سرویسی را از طریق API پرس و جو می کند و داده ها را از آنها در Zabbix جمع آوری می کند.
یکی دیگر از ویژگی های ضروری نظارت، تجسم است. ما بر اساس Grafana است. در بین سایر سیستم های تجسم متمایز است زیرا به شما امکان می دهد معیارها را از منابع داده های مختلف روی داشبورد تجسم کنید. ما می‌توانیم معیارهای سطح بالا را برای یک فروشگاه آنلاین جمع‌آوری کنیم، به عنوان مثال، تعداد سفارش‌های ثبت‌شده در یک ساعت گذشته از DBMS، معیارهای عملکرد سیستم‌عاملی که این فروشگاه آنلاین روی آن اجرا می‌شود از Zabbix، و معیارهایی برای نمونه‌هایی از این برنامه کاربردی. از پرومتئوس و همه اینها روی یک داشبورد خواهد بود. واضح و در دسترس.
اجازه دهید در مورد امنیت یادآوری کنم - ما در حال حاضر در حال نهایی کردن سیستم هستیم که بعداً با سیستم نظارت جهانی یکپارچه خواهیم کرد. به نظر من عمده ترین مشکلاتی که تجارت الکترونیک در حوزه امنیت اطلاعات با آن مواجه است مربوط به ربات ها، تجزیه کننده ها و بروت فورس است. ما باید مراقب این موضوع باشیم، زیرا همه اینها می‌توانند هم بر عملکرد برنامه‌های کاربردی و هم بر شهرت ما از نقطه نظر تجاری تأثیر بگذارند. و با پشته انتخاب شده ما با موفقیت این وظایف را پوشش می دهیم.
نکته مهم دیگر این است که لایه کاربردی توسط Prometheus مونتاژ می شود. او خود نیز با Zabbix ادغام شده است. و همچنین سایت سرعت را داریم، سرویسی که به ما امکان می دهد پارامترهایی مانند سرعت بارگذاری صفحه، تنگناها، رندر صفحه، بارگذاری اسکریپت ها و غیره را مشاهده کنیم، همچنین API یکپارچه است. بنابراین معیارهای ما در Zabbix جمع آوری می شوند و بر این اساس، ما نیز از آنجا هشدار می دهیم. همه هشدارها در حال حاضر به روش‌های اصلی ارسال ارسال می‌شوند (در حال حاضر ایمیل و تلگرام است، تیم‌های ام‌اس نیز اخیراً متصل شده‌اند). برنامه هایی برای ارتقای هشدار به چنین وضعیتی وجود دارد که ربات های هوشمند به عنوان یک سرویس کار کنند و اطلاعات نظارتی را به همه تیم های محصول علاقه مند ارائه کنند.
برای ما، معیارها نه تنها برای سیستم‌های اطلاعاتی فردی، بلکه معیارهای کلی برای کل زیرساختی که برنامه‌ها استفاده می‌کنند مهم هستند: خوشه‌هایی از سرورهای فیزیکی که ماشین‌های مجازی روی آنها اجرا می‌شوند، متعادل‌کننده‌های ترافیک، متعادل‌کننده‌های بار شبکه، خود شبکه، استفاده از کانال‌های ارتباطی. . معیارهای به علاوه برای مراکز داده خودمان (چندتا از آنها را داریم و زیرساخت بسیار بزرگ است).
مزایای سیستم مانیتورینگ ما این است که با کمک آن وضعیت سلامت همه سیستم ها را می بینیم و می توانیم تأثیر آنها را بر یکدیگر و منابع مشترک ارزیابی کنیم. و در نهایت، به ما امکان می دهد در برنامه ریزی منابع شرکت کنیم، که مسئولیت ما نیز هست. ما منابع سرور را مدیریت می کنیم - استخری در تجارت الکترونیک، تجهیزات جدید را کمیسیون و از کار انداخته، تجهیزات جدید اضافی خریداری می کنیم، ممیزی استفاده از منابع را انجام می دهیم و غیره. هر سال، تیم‌ها پروژه‌های جدیدی را برنامه‌ریزی می‌کنند، سیستم‌های خود را توسعه می‌دهند و برای ما مهم است که منابع را برای آنها فراهم کنیم.
و با کمک معیارها، شاهد روند مصرف منابع توسط سیستم های اطلاعاتی خود هستیم. و بر اساس آنها می توانیم چیزی را برنامه ریزی کنیم. در سطح مجازی سازی، داده ها را جمع آوری می کنیم و اطلاعات مربوط به میزان منابع موجود توسط مرکز داده را مشاهده می کنیم. و در حال حاضر در مرکز داده می توانید بازیافت، توزیع واقعی و مصرف منابع را مشاهده کنید. علاوه بر این، هم با سرورهای مستقل و هم با ماشین‌های مجازی و خوشه‌هایی از سرورهای فیزیکی که همه این ماشین‌های مجازی به شدت در حال چرخش هستند.
چشم انداز
اکنون هسته اصلی سیستم را به طور کلی آماده کرده ایم، اما هنوز چیزهای زیادی وجود دارد که هنوز باید روی آنها کار شود. حداقل، این یک لایه امنیت اطلاعات است، اما رسیدن به شبکه، توسعه هشدار و حل مسئله همبستگی نیز مهم است. ما لایه ها و سیستم های زیادی داریم و در هر لایه معیارهای بسیار بیشتری وجود دارد. معلوم می شود که ماتریوشکا در حد یک ماتریوشکا است.
وظیفه ما در نهایت ایجاد هشدارهای مناسب است. مثلا اگر مشکل از سخت افزار بود باز با ماشین مجازی و برنامه مهمی بود و به هیچ وجه از سرویس بک آپ گرفته نشد. متوجه می شویم که ماشین مجازی مرده است. سپس معیارهای تجاری به شما هشدار می دهند: کاربران در جایی ناپدید شده اند، هیچ تبدیلی وجود ندارد، رابط کاربری در رابط در دسترس نیست، نرم افزار و خدمات نیز از بین رفته اند.
در این شرایط، ما هرزنامه ها را از هشدارها دریافت خواهیم کرد و این دیگر در قالب یک سیستم نظارتی مناسب نمی گنجد. سوال همبستگی مطرح می شود. بنابراین، در حالت ایده‌آل، سیستم مانیتورینگ ما باید به جای بمباران خشمگینانه صدها هشدار، بگوید: "بچه‌ها، ماشین فیزیکی شما مرده است و همراه با آن این برنامه و این معیارها" با کمک یک هشدار. باید نکته اصلی - علت را گزارش کند که به دلیل محلی سازی آن به رفع سریع مشکل کمک می کند.
سیستم اعلان و پردازش هشدار ما حول یک سرویس خط تلفن XNUMX ساعته ساخته شده است. تمام هشدارهایی که جزو موارد ضروری محسوب می شوند و در چک لیست گنجانده شده اند به آنجا ارسال می شوند. هر هشدار باید توصیفی داشته باشد: چه اتفاقی افتاده است، در واقع چه معنایی دارد، چه تاثیری دارد. و همچنین پیوندی به داشبورد و دستورالعمل هایی در مورد اینکه در این مورد چه باید کرد.
این همه در مورد الزامات ایجاد هشدار است. سپس وضعیت می تواند در دو جهت توسعه یابد - یا مشکلی وجود دارد و باید حل شود، یا نقصی در سیستم نظارت رخ داده است. اما در هر صورت، شما باید بروید و آن را کشف کنید.
به طور متوسط، با در نظر گرفتن این واقعیت که ارتباط هشدارها هنوز به درستی پیکربندی نشده است، در حال حاضر روزانه حدود صد هشدار دریافت می کنیم. و اگر نیاز به انجام کارهای فنی داشته باشیم و به زور چیزی را خاموش کنیم، تعداد آنها به میزان قابل توجهی افزایش می یابد.
سیستم نظارت علاوه بر نظارت بر سیستم‌هایی که کار می‌کنیم و جمع‌آوری معیارهایی که از نظر ما مهم هستند، به ما امکان می‌دهد داده‌ها را برای تیم‌های محصول جمع‌آوری کنیم. آنها می توانند بر ترکیب معیارها در سیستم های اطلاعاتی که نظارت می کنیم تأثیر بگذارند.
ممکن است همکار ما بیاید و بخواهد معیاری را اضافه کند که هم برای ما و هم برای تیم مفید باشد. یا به عنوان مثال، تیم ممکن است معیارهای اولیه ای را که ما داریم به اندازه کافی نداشته باشد؛ آنها باید برخی از معیارهای خاص را ردیابی کنند. در گرافانا برای هر تیم فضایی ایجاد می کنیم و حقوق ادمین را اعطا می کنیم. همچنین، اگر تیمی به داشبورد نیاز دارد، اما خودشان نمی توانند/نمی دانند چگونه این کار را انجام دهند، ما به آنها کمک می کنیم.
از آنجایی که ما خارج از جریان ارزش آفرینی تیم، انتشار و برنامه ریزی آنها هستیم، به تدریج به این نتیجه می رسیم که نسخه های همه سیستم ها یکپارچه هستند و می توانند روزانه بدون هماهنگی با ما عرضه شوند. و نظارت بر این نسخه‌ها برای ما مهم است، زیرا می‌توانند به طور بالقوه بر عملکرد برنامه تأثیر بگذارند و چیزی را خراب کنند، و این بسیار مهم است. برای مدیریت نسخه‌ها، از Bamboo استفاده می‌کنیم، جایی که داده‌ها را از طریق API دریافت می‌کنیم و می‌توانیم ببینیم کدام نسخه‌ها در کدام سیستم‌های اطلاعاتی منتشر شده‌اند و وضعیت آنها. و مهمترین چیز این است که در چه ساعتی. ما نشانگرهای انتشار را روی معیارهای مهم اصلی قرار می دهیم، که از نظر بصری در صورت بروز مشکلات بسیار نشان دهنده است.
به این ترتیب ما می توانیم ارتباط بین نسخه های جدید و مشکلات در حال ظهور را مشاهده کنیم. ایده اصلی این است که بفهمیم سیستم در همه لایه ها چگونه کار می کند، به سرعت مشکل را بومی سازی کرده و به همان سرعت آن را برطرف کنیم. از این گذشته، اغلب اتفاق می افتد که آنچه بیشترین زمان را می گیرد حل مشکل نیست، بلکه جستجوی علت است.
و در این زمینه در آینده می خواهیم بر روی فعال بودن تمرکز کنیم. در حالت ایده‌آل، من می‌خواهم از قبل و نه بعد از واقعیت، درباره یک مشکل نزدیک بدانم تا بتوانم به جای حل آن، از آن جلوگیری کنم. گاهی اوقات هشدارهای کاذب سیستم مانیتورینگ هم به دلیل خطای انسانی و هم به دلیل تغییرات در برنامه رخ می دهد و ما روی این کار کار می کنیم، آن را دیباگ می کنیم و سعی می کنیم قبل از هرگونه دستکاری در سیستم مانیتورینگ به کاربرانی که از آن استفاده می کنند در این مورد هشدار دهیم. ، یا این فعالیت ها را در پنجره فنی انجام دهید.
بنابراین سیستم راه اندازی شده و از ابتدای بهار با موفقیت کار می کند ... و سود بسیار واقعی را نشان می دهد. البته این نسخه نهایی آن نیست، ما ویژگی های مفید بیشتری را معرفی خواهیم کرد. اما در حال حاضر، با ادغام ها و برنامه های کاربردی بسیار، نظارت بر اتوماسیون واقعاً اجتناب ناپذیر است.
اگر پروژه های بزرگ با تعداد قابل توجهی ادغام را نیز رصد می کنید، در نظرات بنویسید چه گلوله نقره ای برای این کار پیدا کردید.
منبع: www.habr.com