لقد كتبت بالفعل في منشوراتي عن حبري عن تجربتي في بناء الشراكات مع فريقي ( يتحدث عن كيفية إبرام اتفاقية شراكة عند بدء عمل تجاري جديد حتى لا ينهار العمل). والآن أود أن أتحدث عن كيفية بناء شراكات مع العملاء، لأنه بدونهم لن يكون هناك شيء ينهار. آمل أن تكون هذه المقالة مفيدة للشركات الناشئة التي بدأت في بيع منتجاتها للشركات الكبيرة.
أنا حاليا أرأس شركة ناشئة تسمى MONQ Digital Lab، حيث أقوم أنا وفريقي بتطوير منتج لأتمتة عمليات دعم وتشغيل تكنولوجيا المعلومات للشركات. دخول السوق ليس مهمة سهلة، وقد بدأنا بالقليل من الواجبات المنزلية، وراجعنا خبراء السوق وشركائنا وقمنا بتجزئة السوق. كان السؤال الرئيسي هو فهم "آلام من يمكننا أن نعالجها بشكل أفضل؟"
وصلت البنوك إلى أعلى 3 قطاعات. وبالطبع، كان Tinkoff وSberbank الأول في القائمة. عندما قمنا بزيارة خبراء السوق المصرفية، قالوا: قدم منتجك هناك، وسيكون الطريق إلى السوق المصرفية مفتوحاً. لقد حاولنا الدخول هناك وهناك، لكن الفشل كان ينتظرنا في سبيربنك، وكان الرجال من تينكوف أكثر انفتاحًا على التواصل المثمر مع الشركات الناشئة الروسية (ربما يرجع ذلك إلى حقيقة أن سبير في ذلك الوقت ما يقرب من مليار من منافسينا الغربيين). وفي غضون شهر بدأنا مشروعًا تجريبيًا. كيف حدث ذلك، واصل القراءة.
لقد تعاملنا مع قضايا التشغيل والمراقبة لسنوات عديدة، والآن نقوم بتنفيذ منتجنا في القطاع العام، في التأمين، في البنوك، في شركات الاتصالات، وكان التنفيذ واحدًا مع شركة طيران (قبل المشروع، لم نقم حتى أعتقد أن الطيران كان صناعة تعتمد على تكنولوجيا المعلومات، والآن نأمل حقًا، على الرغم من فيروس كورونا، أن تظهر الشركة وتنطلق).
ينتمي المنتج الذي نصنعه إلى برامج المؤسسات، أو قطاع AIOps (الذكاء الاصطناعي لعمليات تكنولوجيا المعلومات، أو ITOps). الأهداف الرئيسية لتنفيذ مثل هذه الأنظمة مع زيادة مستوى نضج العملية في الشركة:
- إخماد الحرائق: تحديد حالات الفشل، ومسح تدفق التنبيهات من الحطام، وإسناد المهام والحوادث إلى المسؤولين عنها؛
- زيادة كفاءة خدمة تكنولوجيا المعلومات: تقليل الوقت اللازم لحل الحوادث، والإشارة إلى أسباب الفشل، وزيادة شفافية حالة تكنولوجيا المعلومات؛
- زيادة كفاءة العمل: تقليل كمية العمل اليدوي، تقليل المخاطر، زيادة ولاء العملاء.
من خلال تجربتنا، تعاني البنوك من "المشاكل" التالية المتعلقة بالمراقبة المشتركة مع جميع البنى التحتية الكبيرة لتكنولوجيا المعلومات:
- "من يعرف ماذا": هناك العديد من الأقسام الفنية، وكل شخص تقريبًا لديه نظام مراقبة واحد على الأقل، ومعظمها لديه أكثر من نظام واحد؛
- "سرب البعوض" من التنبيهات: كل نظام يولد المئات ويقصف كل المسؤولين عنها (وأحيانًا أيضًا بين الأقسام). من الصعب الحفاظ باستمرار على تركيز المراقبة على كل إخطار، حيث يتم تسوية مدى إلحاحها وأهميتها بسبب العدد الكبير؛
- البنوك الكبيرة - قادة القطاع لا يريدون فقط مراقبة أنظمتهم بشكل مستمر، ومعرفة أماكن الفشل، ولكن أيضًا السحر الحقيقي للذكاء الاصطناعي - لجعل الأنظمة تراقب نفسها وتتنبأ وتصحح نفسها بنفسها.
عندما وصلنا إلى الاجتماع الأول في تينكوف، قيل لنا على الفور أنه ليس لديهم أي مشاكل في المراقبة ولا شيء يؤذيهم، وكان السؤال الرئيسي هو: "ماذا يمكننا أن نقدم لأولئك الذين يقومون بعمل جيد بالفعل؟"
كانت المحادثة طويلة، وناقشنا كيفية بناء خدماتهم الصغيرة، وكيفية عمل الأقسام، وما هي مشاكل البنية التحتية الأكثر حساسية، والتي تكون أقل حساسية للمستخدمين، وأين توجد "النقاط العمياء"، وما هي أهدافهم واتفاقيات مستوى الخدمة.
بالمناسبة، اتفاقيات مستوى الخدمة الخاصة بالبنك مثيرة للإعجاب حقًا. على سبيل المثال، قد يستغرق حل مشكلة توفر الشبكة ذات الأولوية XNUMX بضع دقائق فقط. تكلفة الخطأ والتوقف هنا، بطبيعة الحال، مثيرة للإعجاب.
ونتيجة لذلك، حددنا عدة مجالات للتعاون:
- المرحلة الأولى هي المراقبة الشاملة لزيادة سرعة حل الحادث
- والمرحلة الثانية هي أتمتة العمليات لتقليل المخاطر وخفض التكاليف لتوسيع نطاق قسم تكنولوجيا المعلومات.
لا يمكن رسم العديد من "النقاط البيضاء" بألوان التنبيهات الزاهية إلا من خلال معالجة المعلومات من أنظمة مراقبة متعددة، لأنه كان من المستحيل أخذ المقاييس بشكل مباشر؛ وكان من الضروري أيضًا تجميع البيانات من أنظمة مراقبة مختلفة على "شاشة واحدة" من أجل لفهم الصورة الشاملة لما كان يحدث. "المظلات" مناسبة لهذه المهمة وقد استوفينا هذه المتطلبات حينها.
في رأينا، الشيء المهم جدًا في العلاقات مع العملاء هو الصدق. بعد المحادثة الأولى وحساب تكلفة الترخيص، قيل أنه نظرًا لأن التكلفة منخفضة للغاية، فقد يكون من المفيد شراء ترخيص على الفور (مقارنة بـ Dynatrace Klyuch-Astrom من المقالة أعلاه حول البنك الأخضر، لدينا تكاليف الترخيص ليست ثلث مليار، ولكن 12 ألف روبل شهريا مقابل 1 غيغابايت، بالنسبة لـ Sber سيكلف عدة مرات أرخص). لكننا أخبرناهم على الفور بما لدينا وما ليس لدينا. ربما يستطيع مندوب مبيعات من شركة تكامل كبيرة أن يقول "نعم، يمكننا أن نفعل كل شيء، وبالطبع شراء ترخيصنا"، لكننا قررنا وضع كل أوراقنا على الطاولة. في وقت الإطلاق، لم يكن صندوقنا متكاملاً مع Prometheus، وكان إصدار جديد مزود بنظام فرعي للأتمتة على وشك الإصدار، لكننا لم نشحنه إلى العملاء بعد.
بدأ المشروع التجريبي، وتم تحديد حدوده وتم منحنا شهرين. وكانت المهام الرئيسية:
- إعداد نسخة جديدة من المنصة ونشرها في البنية التحتية للبنك
- ربط نظامي مراقبة (Zabbix وPrometheus)؛
- إرسال إشعارات إلى المسؤولين في Slack وعبر الرسائل النصية القصيرة؛
- تشغيل البرامج النصية للإصلاح التلقائي.
تم قضاء الشهر الأول من المشروع التجريبي في إعداد نسخة جديدة من النظام الأساسي في وضع فائق السرعة لتلبية احتياجات المشروع التجريبي. يتضمن الإصدار الجديد على الفور التكامل مع Prometheus والشفاء التلقائي. بفضل فريق التطوير لدينا، لم ينموا لعدة ليالٍ، لكنهم أصدروا ما وعدوا به دون تفويت المواعيد النهائية للالتزامات الأخرى التي تم التعهد بها مسبقًا.
أثناء قيامنا بإعداد البرنامج التجريبي، واجهنا مشكلة جديدة قد تؤدي إلى إغلاق المشروع قبل الموعد المحدد: لإرسال تنبيهات إلى برامج المراسلة الفورية وعبر الرسائل القصيرة، كنا بحاجة إلى اتصالات واردة وصادرة بخوادم Microsoft Azure (في ذلك الوقت استخدمنا هذا النظام الأساسي) لإرسال تنبيهات إلى Slack) وخدمة إرسال رسائل نصية قصيرة (SMS) خارجية. ولكن في هذا المشروع، كانت السلامة موضع تركيز خاص. ووفقاً لسياسة البنك، لا يمكن فتح مثل هذه "الثقوب" تحت أي ظرف من الظروف. كان على كل شيء أن يعمل من حلقة مغلقة. عُرض علينا استخدام واجهة برمجة التطبيقات (API) الخاصة بخدماتنا الداخلية التي ترسل تنبيهات إلى Slack وعبر الرسائل النصية القصيرة، لكن لم تتح لنا الفرصة لتوصيل هذه الخدمات خارج الصندوق.
وانتهت أمسية من النقاش مع فريق التطوير بالبحث الناجح عن حل. بعد البحث في الأعمال المتراكمة، وجدنا مهمة واحدة لم يكن لدينا ما يكفي من الوقت والأولوية لها - وهي إنشاء نظام إضافي حتى يتمكن فريق التنفيذ أو العميل من كتابة الوظائف الإضافية بأنفسهم، مما يؤدي إلى توسيع إمكانيات النظام الأساسي.
ولكن كان لدينا شهر بالضبط، حيث كان علينا تثبيت كل شيء وتكوين ونشر الأتمتة.
وفقًا لسيرجي، كبير المهندسين لدينا، يستغرق تنفيذ نظام المكونات الإضافية شهرًا على الأقل.
لم يكن لدينا وقت...
لم يكن هناك سوى حل واحد - اذهب إلى العميل وأخبره بكل شيء كما هو. ناقش تغيير الموعد النهائي معًا. وقد نجحت. لقد حصلنا على أسبوعين إضافيين. كان لديهم أيضًا مواعيد نهائية والتزامات داخلية خاصة بهم لإظهار النتائج، لكن كان لديهم أسبوعين احتياطيين. وفي النهاية، نضع كل شيء على المحك. كان من المستحيل الفوضى. لقد أتى الصدق ونهج الشراكة بثمارهما مرة أخرى.
ونتيجة لهذا المشروع التجريبي، تم التوصل إلى العديد من النتائج والاستنتاجات الفنية الهامة:
لقد اختبرنا الوظيفة الجديدة لمعالجة التنبيهات
بدأ النظام المنشور في تلقي التنبيهات بشكل صحيح من بروميثيوس وتجميعها. كانت التنبيهات بشأن المشكلة من عميل Prometheus تنطلق كل 30 ثانية (لم يتم تمكين التجميع حسب الوقت)، وكنا نتساءل عما إذا كان من الممكن تجميعها في "المظلة" نفسها. اتضح أنه من الممكن - يتم تنفيذ إعداد معالجة التنبيهات في النظام الأساسي بواسطة برنامج نصي. وهذا يجعل من الممكن تنفيذ أي منطق تقريبًا لمعالجتها. لقد قمنا بالفعل بتطبيق المنطق القياسي في النظام الأساسي في شكل قوالب - إذا كنت لا ترغب في التوصل إلى شيء خاص بك، فيمكنك استخدام شيء جاهز.
واجهة "الزناد الاصطناعي". إعداد معالجة التنبيهات من أنظمة المراقبة المتصلة
بناء حالة "صحة" النظام
استنادًا إلى التنبيهات، تم إنشاء أحداث المراقبة التي أثرت على سلامة وحدات التكوين (CUs). نحن نقوم بتنفيذ نموذج خدمة الموارد (RSM)، والذي يمكنه استخدام إما CMDB داخلي أو توصيل واحد خارجي - أثناء المشروع التجريبي، لم يقم العميل بتوصيل CMDB الخاص به.
واجهة للعمل مع نموذج خدمة الموارد. الطيار آر إس إم.
حسنًا، في الواقع، أصبح لدى العميل أخيرًا شاشة مراقبة واحدة، حيث تكون الأحداث من أنظمة مختلفة مرئية. حاليًا، هناك نظامان متصلان بـ "المظلة" - Zabbix وPrometheus، ونظام مراقبة داخلي للمنصة نفسها.
واجهة التحليلات. شاشة مراقبة واحدة.
تم إطلاق أتمتة العملية
أدت مراقبة الأحداث إلى إطلاق إجراءات تم تكوينها مسبقًا - إرسال التنبيهات، وتشغيل البرامج النصية، وتسجيل/إثراء الأحداث - ولم يتم تجربة الإجراء الأخير مع هذا العميل تحديدًا، لأنه وفي المشروع التجريبي لم يكن هناك تكامل مع مكتب الخدمة.
واجهة إعدادات الإجراء. أرسل تنبيهات إلى Slack وأعد تشغيل الخادم.
وظائف المنتج الموسعة
عند مناقشة البرامج النصية للأتمتة، طلب العميل دعم bash وواجهة يمكن من خلالها تكوين هذه البرامج النصية بشكل ملائم. لقد حقق الإصدار الجديد أكثر من ذلك بقليل (القدرة على كتابة بنيات منطقية كاملة في Lua مع دعم cURL وSSH وSNMP) ونفذ وظائف تسمح لك بإدارة دورة حياة البرنامج النصي (الإنشاء والتحرير والتحكم في الإصدار والحذف والأرشفة).
واجهة للعمل مع البرامج النصية للإصلاح التلقائي. البرنامج النصي لإعادة تشغيل الخادم عبر SSH.
النتائج الرئيسية
أثناء الإصدار التجريبي، تم أيضًا إنشاء قصص المستخدمين لتحسين الوظائف الحالية وزيادة القيمة للعميل، وإليك بعضًا منها:
- تنفيذ القدرة على إعادة توجيه المتغيرات مباشرة من التنبيه إلى البرنامج النصي للإصلاح التلقائي؛
- إضافة ترخيص إلى النظام الأساسي عبر Active Directory.
وقد تلقينا المزيد من التحديات العالمية - "لبناء" المنتج بقدرات أخرى:
- البناء التلقائي لنموذج خدمة الموارد على أساس التعلم الآلي، بدلاً من القواعد والوكلاء (وربما التحدي الرئيسي الآن)؛
- دعم لغات البرمجة والمنطق الإضافية (وسيكون هذا جافا سكريبت).
في رأيي، الشيء الأكثر أهميةما يوضحه هذا الطيار هو أمرين:
- إن الشراكات مع العميل هي مفتاح الفعالية، عندما يكون التواصل الفعال مبنياً على أساس الصدق والصراحة، ويصبح العميل جزءاً من فريق يحقق نتائج مهمة في وقت قصير.
- ليس من الضروري تحت أي ظرف من الظروف "تخصيص" وبناء "العكازات" - فقط حلول النظام. من الأفضل قضاء المزيد من الوقت، ولكن إنشاء حل النظام الذي سيتم استخدامه من قبل العملاء الآخرين. بالمناسبة، هذا ما حدث، قدم نظام البرنامج المساعد وإلغاء الاعتماد على Azure قيمة إضافية للعملاء الآخرين (مرحبًا، القانون الاتحادي 152).
المصدر: www.habr.com