هر برنامه اتوماسیون سازمانی به همان دیوار برخورد میکند. مسیریابی تیکتهای ServiceNow، رفع انحراف Terraform، چرخش گواهینامهها، تخصیص گروههای Active Directory، استقرار وصلههای SCCM، هماهنگسازی خط لوله CI/CD. ده یا بیست گردشکار اول بهراحتی سرمایهگذاری را توجیه میکنند و محاسبات بازگشت سرمایه تا زمانی درست از آب درمیآید که تعداد گردشکارها به صدها برسد و بخش قابلتوجهی از وقت تیم فناوری اطلاعات از ساختن اتوماسیون جدید به نگهداری اتوماسیونهای موجود و جلوگیری از خرابی آنها منتقل شود.
یک پرتال پرداختکننده جریان احراز هویتش را بازطراحی میکند و گردشکار ثبت ادعا دیگر نمیتواند احراز هویت کند. Salesforce یک بهروزرسانی متادیتا منتشر میکند و یک نگاشت فیلد در خط لوله تبدیل سرنخ به فرصت شروع به نوشتن مقادیر تهی میکند. AWS یک نسخه API را منسوخ میکند و یک Terraform plan که یک سال بدون مشکل اجرا میشد، در هر apply خطای 400 میدهد. کسی یک تیکت ثبت میکند، شخص دیگری متوجه میشود چه چیزی تغییر کرده، آن را اصلاح میکند، تست میکند، رفع را مستقر میکند و در این فاصله فرآیندی که قرار بود خودکار باشد یا بهصورت دستی اجرا شده یا اصلاً اجرا نشده است.
این تله نگهداری است و ماهیتی ساختاری دارد، نه نتیجه پیادهسازی ضعیف. اتوماسیون سنتی مسیرهای دقیق را دنبال میکند، الگوهای دقیق را تطبیق میدهد و لحظهای که واقعیت از آنچه در زمان نوشتن گردشکار وجود داشت منحرف شود، میشکند. تحقیقات سازگار است: سازمانها ۷۰ تا ۷۵ درصد کل هزینههای برنامه اتوماسیون خود را نه صرف ساختن گردشکارهای جدید، بلکه صرف نگهداری گردشکارهای موجود میکنند. در استقرارهای بزرگ، ۴۵ درصد گردشکارها هر هفته دچار خرابی میشوند.
موتور گردشکار Triggerfish برای تغییر این وضعیت ساخته شده است. گردشکارهای خودترمیم امروز عرضه میشوند و مهمترین قابلیت پلتفرم تا به امروز هستند.
خودترمیمی واقعاً به چه معناست
این عبارت بهصورت مبهم استفاده میشود، پس اجازه دهید صریح بگویم این دقیقاً چیست.
وقتی خودترمیمی را روی یک گردشکار Triggerfish فعال میکنید، لحظهای که آن گردشکار شروع به اجرا میکند یک عامل سرپرست ایجاد میشود. این عامل وقتی چیزی خراب شود راهاندازی نمیشود؛ از همان قدم اول در حال نظارت است، جریان رویدادهای زنده را از موتور دریافت میکند و هر مرحله را در لحظه مشاهده میکند.
عامل سرپرست قبل از اجرای حتی یک مرحله، تعریف کامل گردشکار را میشناسد، شامل هدف پشت هر مرحله، اینکه هر مرحله از مراحل قبلی چه انتظاری دارد و چه چیزی برای مراحل بعدی تولید میکند. همچنین تاریخچه اجراهای قبلی را میداند: چه چیزی موفق شد، چه چیزی شکست خورد، چه وصلههایی پیشنهاد شد و آیا یک انسان آنها را تأیید یا رد کرد. وقتی چیزی را شناسایی میکند که ارزش اقدام دارد، تمام این زمینه از قبل در حافظهاش هست زیرا از ابتدا نظارهگر بوده و نه اینکه بعد از وقوع بازسازی کرده باشد.
وقتی مشکلی پیش میآید، عامل سرپرست آن را اولویتبندی میکند. یک فراخوانی شبکهای ناپایدار با تلاش مجدد و تأخیر تصاعدی دوباره امتحان میشود. یک نقطه پایانی API تغییریافته که میتوان دورش زد، برای این اجرا دور زده میشود. یک مشکل ساختاری در تعریف گردشکار بهصورت یک اصلاح پیشنهادی برای تکمیل اجرا اعمال میشود و تغییر برای تأیید شما ارسال میگردد تا قبل از دائمی شدن بررسیاش کنید. یک ادغام پلاگین خراب منجر به نوشتن یک پلاگین جدید یا بهروزشده و ارسال آن برای بررسی میشود. اگر عامل سرپرست تلاشهایش را به پایان برساند و نتواند مشکل را حل کند، آن را با یک تشخیص ساختاریافته از آنچه امتحان کرده و آنچه فکر میکند علت ریشهای است، به شما اطلاع میدهد.
گردشکار هر جا که بتواند با امنیت ادامه دهد، به اجرا ادامه میدهد. اگر مرحلهای مسدود شده باشد، فقط مراحل پاییندستی که به آن وابستهاند متوقف میشوند و شاخههای موازی به کارشان ادامه میدهند. عامل سرپرست گراف وابستگی را میشناسد و فقط آنچه واقعاً مسدود شده را متوقف میکند.
چرا زمینهای که در گردشکارها میسازید اهمیت دارد
چیزی که خودترمیمی را در عمل کارآمد میکند این است که گردشکارهای Triggerfish از همان لحظه نوشتن، به متادیتای غنی در سطح مرحله نیاز دارند. این اختیاری نیست و مستندسازی صرف هم نیست؛ این همان چیزی است که عامل سرپرست بر اساس آن استدلال میکند.
هر مرحله در یک گردشکار فراتر از خود تعریف وظیفه، چهار فیلد اجباری دارد: توضیحی از آنچه مرحله بهصورت مکانیکی انجام میدهد، بیانیه هدف که توضیح میدهد چرا این مرحله وجود دارد و چه هدف کسبوکاری را دنبال میکند، فیلد انتظارات که توصیف میکند چه دادهای را فرض میکند دریافت خواهد کرد و مراحل قبلی باید در چه وضعیتی باشند، و فیلد تولیدات که توصیف میکند چه چیزی را در زمینه اجرا برای مصرف مراحل پاییندستی مینویسد.
بیایید ببینیم این در عمل چگونه به نظر میرسد. فرض کنید دارید تخصیص دسترسی کارمندان را خودکار میکنید. یک نیروی جدید دوشنبه شروع به کار میکند و گردشکار باید حسابهایی در Active Directory بسازد، عضویت سازمانی GitHub را تخصیص دهد، گروههای Okta را اختصاص دهد و یک تیکت Jira برای تأیید تکمیل باز کند. یک مرحله رکورد کارمند را از سیستم منابع انسانی دریافت میکند. فیلد هدف آن صرفاً نمیگوید «رکورد کارمند را بگیر.» بلکه مینویسد: «این مرحله منبع حقیقت برای هر تصمیم تخصیص دسترسی پاییندستی است. نقش، بخش و تاریخ شروع از این رکورد تعیین میکنند کدام گروههای Active Directory اختصاص یابند، کدام تیمهای GitHub تخصیص داده شوند و کدام سیاستهای Okta اعمال شوند. اگر این مرحله داده ناقص یا قدیمی برگرداند، هر مرحله پاییندستی دسترسی اشتباه تخصیص خواهد داد.»
عامل سرپرست آن بیانیه هدف را هنگام شکست مرحله میخواند و درک میکند چه چیزی در خطر است. میداند که یک رکورد ناقص به این معناست که مراحل تخصیص دسترسی با ورودیهای نادرست اجرا خواهند شد و احتمالاً مجوزهای اشتباه به یک شخص واقعی که دو روز دیگر شروع به کار میکند اعطا میشود. این زمینه شکل میدهد که چگونه سعی در بازیابی کند، آیا مراحل پاییندستی را متوقف کند و اگر مشکل را اطلاع دهد، چه بگوید.
مرحله دیگری در همان گردشکار فیلد تولیدات مرحله دریافت منابع انسانی را بررسی میکند و میداند که انتظار دارد .employee.role و .employee.department بهعنوان رشتههای غیرخالی دریافت کند. اگر سیستم منابع انسانی شما API خود را بهروز کند و شروع به برگرداندن این فیلدها بهصورت تودرتو زیر .employee.profile.role کند، عامل سرپرست انحراف شِما را شناسایی میکند، یک نگاشت زمان اجرا برای این اجرا اعمال میکند تا نیروی جدید بهدرستی دسترسی بگیرد و یک اصلاح ساختاری برای بهروزرسانی تعریف مرحله پیشنهاد میدهد. شما قاعده مهاجرت شِما یا مدیریت استثنا برای این مورد خاص ننوشتید. عامل سرپرست از زمینهای که از قبل موجود بود به این نتیجه رسید.
به همین دلیل است که کیفیت نوشتن گردشکار اهمیت دارد. متادیتا تشریفات نیست؛ سوختی است که سیستم خودترمیمی با آن کار میکند. گردشکاری با توضیحات سطحی، گردشکاری است که عامل سرپرست در لحظه حساس نمیتواند دربارهاش استدلال کند.
نظارت زنده یعنی گرفتن مشکلات قبل از تبدیل شدن به خرابی
چون عامل سرپرست در لحظه نظارت میکند، میتواند قبل از خرابی واقعی روی سیگنالهای ضعیف اقدام کند. مرحلهای که معمولاً در دو ثانیه تکمیل میشد حالا چهل ثانیه طول میکشد. مرحلهای که در هر اجرای قبلی داده برگردانده بود، نتیجه خالی برمیگرداند. شاخه شرطیای طی میشود که در کل تاریخچه اجرا هرگز طی نشده بود. هیچکدام از اینها خطای سخت نیست و گردشکار به اجرا ادامه میدهد، اما سیگنالهایی هستند که چیزی در محیط تغییر کرده است. بهتر است آنها را قبل از اینکه مرحله بعدی سعی کند داده نامعتبر مصرف کند، بگیریم.
حساسیت این بررسیها برای هر گردشکار قابل تنظیم است. یک گزارشسازی شبانه ممکن است آستانههای آزاد داشته باشد در حالی که یک خط لوله تخصیص دسترسی با دقت بالا نظارت میشود. شما تعیین میکنید چه سطحی از انحراف توجه عامل سرپرست را میطلبد.
گردشکار همچنان متعلق به شماست
عامل سرپرست و تیمش نمیتوانند بدون تأیید شما تعریف اصلی گردشکار را تغییر دهند. وقتی عامل سرپرست یک اصلاح ساختاری پیشنهاد میدهد، اصلاح را برای تکمیل اجرای جاری اعمال کرده و تغییر را بهعنوان پیشنهاد ارسال میکند. شما آن را در صف خود میبینید، استدلال را میبینید و تأیید یا رد میکنید. اگر رد کنید، آن رد ثبت میشود و هر عامل سرپرست آیندهای که روی آن گردشکار کار میکند میداند که همان چیز را دوباره پیشنهاد ندهد.
یک چیز هست که عامل سرپرست صرفنظر از پیکربندی هرگز نمیتواند تغییر دهد: مأموریت خودش. سیاست خودترمیمی در تعریف گردشکار، شامل اینکه آیا متوقف شود، چه مدت تلاش مجدد کند و آیا تأیید لازم باشد، سیاستی است که مالک نوشته است. عامل سرپرست میتواند تعاریف وظایف را وصله کند، فراخوانیهای API را بهروز کند، پارامترها را تنظیم کند و پلاگینهای جدید بنویسد. اما نمیتواند قوانین حاکم بر رفتار خودش را تغییر دهد. این مرز بهصورت سختافزاری کدگذاری شده است. عاملی که بتواند الزام تأیید حاکم بر پیشنهادات خودش را غیرفعال کند، کل مدل اعتماد را بیمعنا میکند.
تغییرات پلاگین نیز همان مسیر تأیید هر پلاگین نوشتهشده توسط عامل در Triggerfish را طی میکنند. اینکه پلاگین برای رفع یک گردشکار خراب نوشته شده، هیچ اعتماد ویژهای به آن نمیدهد. همان بررسیای را طی میکند که انگار از عامل خواسته بودید یک ادغام جدید از صفر بسازد.
مدیریت این قابلیت از هر کانالی که همین الان استفاده میکنید
نباید مجبور باشید برای اطلاع از وضعیت گردشکارهایتان وارد یک داشبورد جداگانه شوید. اعلانهای خودترمیمی از هر جایی که Triggerfish را برای دسترسی پیکربندی کردهاید میآیند: خلاصه مداخله روی Slack، درخواست تأیید روی Telegram، گزارش اطلاعرسانی از طریق ایمیل. سیستم از کانالی که برای فوریت موضوع مناسب است به شما مراجعه میکند بدون اینکه مجبور باشید یک کنسول نظارتی را مدام بازخوانی کنید.
مدل وضعیت گردشکار برای این منظور ساخته شده است. وضعیت یک رشته ساده نیست بلکه یک شیء ساختاریافته است که هر آنچه یک اعلان برای معنادار بودن نیاز دارد را حمل میکند: وضعیت فعلی، سیگنال سلامت، اینکه آیا وصلهای در صف تأیید شماست، نتیجه آخرین اجرا و اینکه عامل سرپرست در حال حاضر چه کاری انجام میدهد. پیام Slack شما میتواند بگوید «گردشکار تخصیص دسترسی متوقف شده، عامل سرپرست در حال نوشتن اصلاح پلاگین است، تأیید لازم خواهد بود» در یک اعلان واحد بدون جستجوی زمینه.
همان وضعیت ساختاریافته رابط زنده Tidepool را هم تغذیه میکند وقتی تصویر کامل را میخواهید. همان داده، سطح متفاوت.
این واقعاً چه تغییری برای تیمهای فناوری اطلاعات ایجاد میکند
افرادی در سازمان شما که هفتهشان را صرف رفع گردشکارهای خراب میکنند، کار کممهارتی انجام نمیدهند. آنها سیستمهای توزیعشده را اشکالزدایی میکنند، تغییرات API را میخوانند و مهندسی معکوس میکنند که چرا گردشکاری که دیروز خوب کار میکرد امروز خراب شده. این قضاوت ارزشمندی است و در حال حاضر تقریباً بهطور کامل صرف زنده نگهداشتن اتوماسیون موجود میشود به جای ساختن اتوماسیون جدید یا حل مسائل دشوارتر.
گردشکارهای خودترمیم آن قضاوت را حذف نمیکنند، بلکه زمان اعمال آن را تغییر میدهند. به جای آتشنشانی یک گردشکار خراب در نیمهشب، صبح در حال بررسی یک اصلاح پیشنهادی هستید و تصمیم میگیرید آیا تشخیص عامل سرپرست درست است. شما تأییدکننده یک تغییر پیشنهادی هستید، نه نویسنده یک وصله تحت فشار.
این همان مدل کاری است که Triggerfish بر اساس آن ساخته شده: انسانها کار عاملها را بررسی و تأیید میکنند به جای اینکه خودشان کاری را انجام دهند که عاملها قادر به انجامش هستند. پوشش اتوماسیون بالا میرود در حالی که بار نگهداری کاهش مییابد و تیمی که ۷۵ درصد وقتش را صرف نگهداری میکرد، میتواند بیشتر آن زمان را به کارهایی اختصاص دهد که واقعاً به قضاوت انسانی نیاز دارند.
امروز عرضه میشود
گردشکارهای خودترمیم امروز بهعنوان یک قابلیت اختیاری در موتور گردشکار Triggerfish عرضه میشوند. فعالسازی برای هر گردشکار جداگانه و در بلوک متادیتای گردشکار پیکربندی میشود. اگر فعالش نکنید، هیچ چیزی در نحوه اجرای گردشکارهایتان تغییر نمیکند.
این مهم است نه به این دلیل که یک مسئله فنی دشوار است (هرچند هست)، بلکه به این دلیل که مستقیماً به چیزی میپردازد که اتوماسیون سازمانی را گرانتر و دردناکتر از حد لازم کرده است. تیم نگهداری گردشکار باید اولین شغلی باشد که اتوماسیون هوش مصنوعی جایگزینش میکند. این استفاده درست از این فناوری است و این همان چیزی است که Triggerfish ساخته است.
اگر میخواهید عمیقتر بررسی کنید که چگونه کار میکند، مشخصات کامل در مخزن موجود است. اگر میخواهید امتحانش کنید، مهارت workflow-builder شما را در نوشتن اولین گردشکار خودترمیم راهنمایی میکند.