در نشریات Habré، قبلاً در مورد تجربه خود از ایجاد مشارکت با تیمم نوشتم ( در مورد نحوه تنظیم قرارداد مشارکت هنگام شروع یک تجارت جدید صحبت می کند تا تجارت از هم نپاشد). و اکنون می خواهم در مورد نحوه ایجاد مشارکت با مشتریان صحبت کنم، زیرا بدون آنها چیزی برای از هم پاشیدن وجود نخواهد داشت. امیدوارم این مقاله برای استارت آپ هایی که شروع به فروش محصول خود به کسب و کارهای بزرگ کرده اند مفید باشد.
من در حال حاضر سرپرست استارتاپی به نام آزمایشگاه دیجیتال MONQ هستم، جایی که من و تیمم در حال توسعه محصولی برای خودکارسازی فرآیندهای پشتیبانی و عملیاتی IT شرکتی هستیم. ورود به بازار کار ساده ای نیست و ما با کمی تکلیف شروع کردیم، کارشناسان بازار، شرکای خود را مرور کردیم و تقسیم بندی بازار را انجام دادیم. سوال اصلی این بود که بفهمیم "دردهای چه کسانی را بهتر می توانیم التیام دهیم؟"
بانک ها وارد 3 بخش برتر شدند. و البته اولین ها در این لیست Tinkoff و Sberbank بودند. وقتی به بازدید کارشناسان بازار بانکی رفتیم، گفتند: محصول خود را در آنجا معرفی کنید، مسیر بازار بانکی باز می شود. ما سعی کردیم هم آنجا و هم آنجا را وارد کنیم ، اما شکست در Sberbank در انتظار ما بود و بچه های Tinkoff معلوم شد که برای ارتباط سازنده با استارتاپ های روسی بسیار بازتر هستند (شاید به دلیل این واقعیت است که Sber در آن زمان تقریباً یک میلیارد از رقبای غربی ما). در عرض یک ماه یک پروژه آزمایشی را شروع کردیم. چگونه اتفاق افتاد، در ادامه بخوانید.
ما سال هاست با مسائل مربوط به بهره برداری و نظارت سروکار داریم، الان داریم محصول خود را در بخش دولتی، بیمه، بانک، شرکت مخابرات اجرا می کنیم، یک اجرا با شرکت هواپیمایی بود (قبل از پروژه حتی فکر کنید که هوانوردی یک صنعت وابسته به فناوری اطلاعات بود، و اکنون ما واقعاً امیدواریم، علیرغم کووید، این شرکت ظهور کند و راه بیفتد).
محصولی که ما می سازیم متعلق به نرم افزار سازمانی، بخش AIOps (هوش مصنوعی برای عملیات فناوری اطلاعات یا ITOps) است. اهداف اصلی پیاده سازی چنین سیستم هایی به عنوان افزایش سطح بلوغ فرآیند در شرکت:
- خاموش کردن آتش: شناسایی خرابی ها، پاکسازی جریان هشدارها از زباله ها، تعیین وظایف و حوادث به مسئولین.
- افزایش بهره وری خدمات فناوری اطلاعات: کاهش زمان برای حل و فصل حوادث، نشان دادن دلایل خرابی، افزایش شفافیت وضعیت فناوری اطلاعات؛
- افزایش کارایی کسب و کار: کاهش میزان کار دستی، کاهش خطرات، افزایش وفاداری مشتری.
در تجربه ما، بانک‌ها با نظارت مشترک با تمام زیرساخت‌های بزرگ فناوری اطلاعات، مشکلات زیر را دارند:
- "چه کسی چه می داند": بخش های فنی زیادی وجود دارد، تقریباً همه حداقل یک سیستم نظارت دارند و اکثر آنها بیش از یک سیستم دارند.
- "ازدحام پشه ها" از هشدارها: هر سیستم صدها مورد تولید می کند و همه افراد مسئول را با آنها بمباران می کند (گاهی اوقات بین بخش ها). حفظ تمرکز کنترل بر روی هر اعلان دشوار است؛ فوریت و اهمیت آنها به دلیل تعداد زیاد آن کاهش می یابد.
- بانک‌های بزرگ - رهبران بخش‌ها نه تنها می‌خواهند سیستم‌های خود را به طور مداوم زیر نظر داشته باشند، بدانند کجا خراب است، بلکه جادوی واقعی هوش مصنوعی را نیز می‌خواهند - تا سیستم‌ها را خود نظارت، پیش‌بینی و اصلاح کنند.
وقتی به اولین جلسه در Tinkoff آمدیم، بلافاصله به ما گفتند که آنها هیچ مشکلی با نظارت ندارند و هیچ چیزی به آنها آسیب نمی رساند، و سؤال اصلی این بود: "برای کسانی که در حال حاضر خوب کار می کنند چه چیزی می توانیم ارائه دهیم؟"
مکالمه طولانی بود، ما درباره نحوه ساخت میکروسرویس‌های آنها، نحوه عملکرد بخش‌ها، مشکلات زیرساختی حساس‌تر، حساسیت کمتر برای کاربران، «نقاط کور» و اهداف و SLA بحث کردیم.
به هر حال، SLA های بانک واقعاً چشمگیر هستند. برای مثال، حل یک حادثه دسترسی به شبکه اولویت XNUMX ممکن است فقط چند دقیقه طول بکشد. البته هزینه خطا و خرابی در اینجا قابل توجه است.
در نتیجه، ما چندین زمینه همکاری را شناسایی کردیم:
- مرحله اول مانیتورینگ چتری برای افزایش سرعت حل حادثه است
- مرحله دوم اتوماسیون فرآیند برای کاهش خطرات و کاهش هزینه های مقیاس پذیری بخش فناوری اطلاعات است.
چندین "نقطه سفید" را می‌توان با رنگ‌های روشن هشدارها تنها با پردازش اطلاعات از چندین سیستم نظارتی رنگ آمیزی کرد، زیرا نمی‌توان مستقیماً معیارها را اندازه‌گیری کرد؛ همچنین لازم بود داده‌ها از سیستم‌های نظارتی مختلف روی یک صفحه نمایش متمرکز شوند. برای درک تصویر کلی از آنچه اتفاق می افتد. "چترها" برای این کار مناسب هستند و ما در آن زمان این شرایط را برآورده کردیم.
یک چیز بسیار مهم از نظر ما در روابط با مشتریان صداقت است. پس از اولین مکالمه و محاسبه هزینه مجوز، گفته شد که از آنجایی که هزینه آن بسیار کم است، ممکن است ارزش خرید فوری مجوز را داشته باشد (در مقایسه با Dynatrace Klyuch-Astrom از مقاله بالا در مورد بانک سبز، ما هزینه مجوز نه یک سوم میلیارد، بلکه 12 هزار روبل در ماه برای 1 گیگابایت است، برای Sber چندین برابر ارزان تر است). اما بلافاصله به آنها گفتیم که چه داریم و چه نداریم. شاید یک نماینده فروش از یک شرکت بزرگ می تواند بگوید "بله، ما می توانیم همه کارها را انجام دهیم، البته مجوز خود را بخریم"، اما ما تصمیم گرفتیم همه کارت های خود را روی میز بگذاریم. در زمان عرضه، جعبه ما با Prometheus ادغام نشد و نسخه جدیدی با زیرسیستم اتوماسیون در شرف عرضه بود، اما هنوز آن را برای مشتریان ارسال نکرده ایم.
طرح آزمایشی شروع شد، حدود آن مشخص شد و 2 ماه به ما فرصت دادند. وظایف اصلی عبارت بودند از:
- نسخه جدیدی از پلتفرم را آماده کرده و در زیرساخت بانک مستقر کنید
- اتصال 2 سیستم نظارت (Zabbix و Prometheus)؛
- ارسال اعلان ها به مسئولین در Slack و از طریق پیامک.
- اسکریپت های اتوهالینگ را اجرا کنید.
اولین ماه از اجرای پروژه آزمایشی صرف تهیه نسخه جدید پلت فرم در حالت فوق سریع برای نیازهای پروژه آزمایشی شد. نسخه جدید بلافاصله شامل ادغام با Prometheus و درمان خودکار است. به لطف تیم توسعه ما، آنها چندین شب نخوابیدند، اما آنچه را که وعده داده بودند، بدون از دست دادن ضرب الاجل برای سایر تعهدات قبلی، آزاد کردند.
در حالی که ما در حال راه اندازی آزمایشی بودیم، با مشکل جدیدی مواجه شدیم که می تواند پروژه را زودتر از موعد مقرر ببندد: برای ارسال هشدار به پیام رسان های فوری و از طریق SMS، به اتصالات ورودی و خروجی به سرورهای Microsoft Azure نیاز داشتیم (در آن زمان از این پلت فرم استفاده می کردیم. برای ارسال هشدار به Slack) و یک سرویس ارسال پیامک خارجی. اما در این پروژه، ایمنی تمرکز ویژه ای بود. مطابق با سیاست بانک، چنین "چاله هایی" تحت هیچ شرایطی باز نمی شد. همه چیز باید از یک حلقه بسته کار می کرد. به ما پیشنهاد شد از API سرویس های داخلی خودمان استفاده کنیم که هشدارها را به Slack و از طریق پیامک ارسال می کند، اما ما فرصتی برای اتصال چنین خدماتی از جعبه نداشتیم.
یک شب مناظره با تیم توسعه با جستجوی موفقیت آمیز برای راه حل به پایان رسید. پس از جست و جو در بک لاگ، یک کار را پیدا کردیم که هرگز زمان و اولویت کافی برای آن نداشتیم - ایجاد یک سیستم پلاگین به طوری که تیم های پیاده سازی یا مشتری بتوانند خود افزونه هایی بنویسند و قابلیت های پلت فرم را گسترش دهند.
اما دقیقاً یک ماه فرصت داشتیم که در طی آن باید همه چیز را نصب می کردیم، پیکربندی و استقرار اتوماسیون را انجام می دادیم.
به گفته سرگئی، معمار اصلی ما، حداقل یک ماه طول می کشد تا سیستم پلاگین را پیاده سازی کند.
وقت نداشتیم...
تنها یک راه حل وجود داشت - به مشتری بروید و همه چیز را همانطور که هست بگویید. در مورد تغییر مهلت با هم بحث کنید. و کار کرد. 2 هفته دیگر به ما فرصت دادند. آنها هم ضرب الاجل و تعهدات داخلی خود را برای نشان دادن نتیجه داشتند، اما 2 هفته ذخیره داشتند. در پایان، همه چیز را روی خط می گذاریم. به هم ریختن غیرممکن بود. صداقت و رویکرد مشارکت دوباره نتیجه داد.
در نتیجه آزمایش، چندین نتیجه فنی مهم و نتیجه گیری به دست آمد:
ما عملکرد جدید را برای پردازش هشدارها آزمایش کردیم
سیستم مستقر شده شروع به دریافت صحیح هشدارها از Prometheus و گروه بندی آنها کرد. هشدارهای مربوط به مشکل مشتری Prometheus هر 30 ثانیه یکبار پخش می‌شد (گروه‌بندی بر اساس زمان فعال نیست)، و ما نمی‌دانیم که آیا امکان گروه‌بندی آنها در خود "چتر" وجود دارد یا خیر. معلوم شد که ممکن است - تنظیم پردازش هشدارها در پلت فرم توسط یک اسکریپت اجرا می شود. این امکان اجرای تقریباً هر منطقی را برای پردازش آنها فراهم می کند. ما قبلاً منطق استاندارد را در قالب قالب ها در پلتفرم پیاده سازی کرده ایم - اگر نمی خواهید چیزی از خود ایجاد کنید ، می توانید از یک مورد آماده استفاده کنید.
رابط "ماشه مصنوعی". تنظیم پردازش هشدارها از سیستم های نظارتی متصل
وضعیت "سلامت" سیستم را ساخت
بر اساس هشدارها، رویدادهای نظارتی ایجاد شد که بر سلامت واحدهای پیکربندی (CUs) تأثیر گذاشت. ما در حال پیاده‌سازی یک مدل سرویس منبع (RSM) هستیم که می‌تواند از یک CMDB داخلی یا اتصال خارجی استفاده کند - در طول پروژه آزمایشی مشتری CMDB خود را متصل نکرده است.
رابط برای کار با مدل منبع-خدمات. RSM پایلوت.
خوب، در واقع، کلاینت در نهایت یک صفحه مانیتورینگ واحد دارد که رویدادهای سیستم های مختلف در آن قابل مشاهده است. در حال حاضر، دو سیستم به "چتر" متصل هستند - Zabbix و Prometheus، و یک سیستم نظارت داخلی خود پلت فرم.
رابط تجزیه و تحلیل. صفحه مانیتورینگ تک
اتوماسیون فرآیند راه اندازی شد
نظارت بر رویدادها باعث راه‌اندازی اقدامات از پیش پیکربندی شده - ارسال هشدار، اجرای اسکریپت‌ها، ثبت/غنی‌سازی رویدادها شد - مورد دوم با این مشتری خاص آزمایش نشد، زیرا در پروژه آزمایشی هیچ ادغام با میز خدمات وجود نداشت.
رابط تنظیمات عمل. هشدارها را به Slack ارسال کنید و سرور را راه اندازی مجدد کنید.
قابلیت گسترش محصول
هنگام بحث در مورد اسکریپت‌های اتوماسیون، مشتری درخواست پشتیبانی bash و رابطی را می‌دهد که در آن این اسکریپت‌ها به راحتی پیکربندی شوند. نسخه جدید کمی بیشتر انجام داده است (قابلیت نوشتن ساختارهای منطقی کامل در Lua با پشتیبانی از cURL، SSH و SNMP) و عملکردی پیاده سازی شده است که به شما امکان می دهد چرخه زندگی یک اسکریپت (ایجاد، ویرایش، کنترل نسخه) را مدیریت کنید. ، حذف و بایگانی کنید).
رابط برای کار با اسکریپت های خودهیلینگ. اسکریپت راه اندازی مجدد سرور از طریق SSH.
یافته های کلیدی
در طول آزمایشی، داستان های کاربری نیز ایجاد شد که عملکرد فعلی را بهبود می بخشد و ارزش را برای مشتری افزایش می دهد، در اینجا برخی از آنها وجود دارد:
- پیاده سازی توانایی ارسال متغیرها به طور مستقیم از هشدار به اسکریپت autohealing.
- مجوز را از طریق Active Directory به پلتفرم اضافه کنید.
و ما چالش های جهانی بیشتری دریافت کردیم - برای "ساخت" محصول با قابلیت های دیگر:
- ساخت خودکار یک مدل منبع-خدمات مبتنی بر ML، به جای قوانین و عوامل (احتمالاً چالش اصلی اکنون).
- پشتیبانی از زبان های برنامه نویسی و منطق اضافی (و این جاوا اسکریپت خواهد بود).
به نظر من، مهم ترینآنچه این خلبان نشان می دهد دو چیز است:
- شراکت با مشتری کلید اثربخشی است، زمانی که ارتباطات مؤثر بر اساس صداقت و صراحت ساخته شود و مشتری بخشی از تیمی می شود که در مدت زمان کوتاهی به نتایج قابل توجهی می رسد.
- تحت هیچ شرایطی نیازی به "سفارشی کردن" و ساختن "عصا" نیست - فقط راه حل های سیستمی. بهتر است کمی بیشتر وقت بگذارید، اما یک راه حل سیستمی ایجاد کنید که توسط سایر مشتریان استفاده شود. به هر حال، این همان چیزی است که اتفاق افتاد، سیستم افزونه و حذف وابستگی به Azure ارزش بیشتری را برای سایر مشتریان فراهم کرد (سلام، قانون فدرال 152).
منبع: www.habr.com