چطور توافق‌نامه‌ی سطح خدمت بنویسیم که در عمل به کار بیاید؟

«این پلتفرم در ۹۹٫۹ درصد مواقع در دسترس خواهد بود.»

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

توافق‌نامه‌ی سطح خدمت (SLA) مناسب، فقط عدد خوش‌آب‌ورنگی برای زمانِ روشن بودن سرویس نیست. باید خلاصه‌ای کاربردی از روش اداره‌ی سرویسی باشد که دیگران به آن وابسته‌اند. توافق‌نامه باید نتیجه‌ی مورد نیاز کاربر را به رفتار قابل‌اندازه‌گیری وصل کند، وظیفه‌ی هر طرف را روشن سازد و بگوید در شرایط معمول، فشار بیش از ظرفیت، تغییر و خرابی چه تصمیمی می‌گیریم.

این معیار درباره‌ی API مشتری، پلتفرم داده‌ی داخلی، محصول ابریِ مدیریت‌شده، دستیار هوش مصنوعی و حتی گروه بازبینی انسانی‌ای صدق می‌کند که بخشی از گردش‌کار خودکار است.

با یک صفحه، قولِ خدمت را روشن کنید

پیش از بحث درباره‌ی درصدها، در یک صفحه تصمیم‌های زیر را بنویسید. این صفحه هسته‌ی توافق است؛ جزئیات حقوقی و دستورالعمل‌های اجرایی را در صورت نیاز می‌توانید بعداً اضافه کنید.

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

اول مسیر کاربر را ببینید، بعد اجزا را

شاخص‌های زیرساخت لازم‌اند، اما کاربران با یک گردش‌کار سروکار دارند. ممکن است پایگاه داده سالم باشد، اما داشبورد اطلاعات دیروز را نشان دهد. نقطه‌ی پایانی مدل کد HTTP 200 برگرداند، اما ایجنت ابزار اشتباهی را انتخاب کند. بستر سند آنلاین باشد، ولی قوانین دسترسی نگذارد کارمندان مرتبط اطلاعات لازم را پیدا کنند.

اول مسیر کاری‌ای را که قرار است پوشش داده شود تعریف کنید:

در ساعت‌های کاری پشتیبانی، کارشناس مجاز بتواند سیاست فعلی مربوط به یک پرونده‌ی مشمول را پیدا کند و پیش‌نویسی دریافت کند که پیش از مهلت پاسخ قابل‌بازبینی باشد.

این جمله به تیم امکان می‌دهد مسیر را به اجزای روشن‌تری تقسیم کند. سامانه‌ی هویت، بازیابی اطلاعات، به‌روز بودن سیاست، اجرای مدل، کد برنامه و بازبینی انسان همگی بر نتیجه اثر دارند. همچنین موارد خارج از دامنه را به گفت‌وگو می‌آورد: شاید پرونده‌های حقوقیِ غیرمعمول خودکار نشوند؛ پردازش حجیم داده زمان‌بندی جداگانه‌ای از درخواست فوری داشته باشد؛ یا دستیار مجاز به پیش‌نویس باشد، اما اجازه‌ی ارسال نداشته باشد.

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

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

شاخص، هدف و پیامد را از هم جدا نگه دارید

تیم‌های فناوری گاهی سه مفهوم متفاوت را در یک جمله خلاصه می‌کنند:

• شاخص سطح خدمت (SLI): چیزی که مشاهده و اندازه‌گیری می‌کنیم؛ برای نمونه، درصد درخواست‌های معتبری که در کمتر از هشت ثانیه تمام می‌شوند.
• هدف سطح خدمت (SLO): سطح مورد انتظار برای آن شاخص؛ مثلاً ۹۵ درصد درخواست‌های مشمول در یک بازه‌ی چرخان ۲۸روزه.
• توافق‌نامه‌ی سطح خدمت (SLA): تعهد میان طرف‌ها که دامنه، مسئولیت‌ها و پیامد نرسیدن به هدف را مشخص می‌کند.

این تفکیک مهم است؛ هرکدام ممکن است جداگانه ایراد داشته باشند. هدف معقولی که از نقطه‌ی اشتباه اندازه‌گیری می‌شود، اطمینان کاذب می‌دهد. شاخص دقیقی با هدفی دل‌بخواهی می‌تواند تیم را به کار پرهزینه و بی‌دلیل وادار کند. هدفی قراردادی هم اگر واکنشی در پی نداشته باشد، پس از حادثه فقط به اختلاف‌نظر می‌انجامد.

جزئیات اندازه‌گیری را پنهان نکنید. مشخص کنید زمان‌سنج با چه رویدادی شروع و تمام می‌شود، کدام درخواست‌ها در مخرج محاسبه می‌آیند، نگهداری برنامه‌ریزی‌شده چه جایگاهی دارد، منطقه‌ی زمانی ساعت خدمت چیست، پاسخ ناقص چطور حساب می‌شود و اگر اختلافی پیش آمد داده‌ی پایش کدام طرف ملاک است. برای سنجش زمان پاسخ، صدک‌ها اغلب از میانگین گویاترند؛ چون میانگینی قابل‌قبول ممکن است تأخیرهای آزاردهنده‌ی گروهی از کاربران را پنهان کند.

هدف باید از پیامد کار و ظرفیتی که واقعاً آزموده‌ایم بیاید. کاربر تا چه مدت تأخیر را تحمل می‌کند؟ چه مقدار کار ناقص یا اشتباه را می‌توان با اطمینان پیدا کرد؟ سازمان چه مدت بازیابی‌ای را می‌پذیرد؟ معماری فعلی از پس چه باری برمی‌آید؟ بعد هزینه‌ی فاصله‌ی وضع موجود تا هدف را حساب کنید. انتخاب «چهار نُه» (دسترس‌پذیری ۹۹٫۹۹٪) چون حرفه‌ای به نظر می‌رسد، مهندسی قابلیت اطمینان نیست.

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

سرویس را زنجیره‌ای از تعهدها بدانید

بیشتر سرویس‌های امروزی از مرزهای فنی و سازمانی زیادی می‌گذرند. شاید تیم محصول رابط کاربری را اداره کند، تیم پلتفرم محیط اجرا را، تیم داده خط لوله‌ی منبع را، ارائه‌دهنده‌ی بیرونی مدل را، امنیت سیاست دسترسی را و تیم عملیات فرایند پاسخ را. تعهد هر جزء به‌تنهایی موفقیت مسیر کاربر را تضمین نمی‌کند.

کنار صفحه‌ی توافق، فهرستی از وابستگی‌ها داشته باشید. برای هرکدام بنویسید:

• سرویس به چه چیزی از آن وابسته است؛
• آن جزء عملاً چه سطحی از خدمت را وعده می‌دهد؛
• سرویس مصرف‌کننده از کجا متوجه خرابی آن می‌شود؛
• چه راه جایگزینی وجود دارد و کیفیتش چقدر است؛
• چه کسی می‌تواند وابستگی را تغییر دهد، عوض کند یا موضوع را بالا ببرد.

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

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

کیفیت داده و هوش مصنوعی را بسنجید، اما آن را با دسترس‌پذیری اشتباه نگیرید

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

در نتیجه، توافق سطح خدمتِ امروز شاید به چند دسته شاخص نیاز داشته باشد:

• تحویل فنی: دسترس‌پذیری، زمان پاسخ سرتاسری، توان پردازش، نرخ وقفه و بازیابی؛
• وضعیت داده: تازگی، کامل بودن، معتبر بودن ساختار، پوشش منشأ داده و خطای تطبیق؛
• کیفیت انجام کار: موفقیت در آزمون ارزیابی نسخه‌دار، مستند بودن پاسخ، خروجی ساختاریافته‌ی معتبر، تشخیص ناتوانی از پاسخ‌گویی و یافته‌های بازبینی عملیاتی؛
• ایمنی اقدام: نقض مجوز، تلاش غیرمجاز برای فراخوانی ابزار، اقدام برگشت‌ناپذیر یا دور زدن تأیید؛
• تجربه‌ی انسانی: سن صف بازبینی، نرخ دخالت، استثناهای حل‌نشده و دسته‌بندی خطاهایی که کاربران گزارش می‌کنند.

این‌ها را در یک نمره‌ی مرکب ادغام نکنید؛ وگرنه هیچ‌کس نمی‌فهمد عدد نهایی چه معنایی دارد. به هر شاخص یک تصمیم وصل کنید. مثلاً بالا رفتن تأخیر می‌تواند ترافیک را به مدل سریع‌تری ببرد. قدیمی بودن منبع داده شاید باعث شود آخرین زمان به‌روزرسانی را نشان دهیم و پیشنهادهای حساس را متوقف کنیم. افت نتیجه‌ی ارزیابی هم می‌تواند انتشار نسخه‌ی جدید پرامپت، مدل یا روش بازیابی را متوقف کند، حتی اگر سرویس از نظر دسترس‌پذیری بی‌نقص باشد.

بخش اصلی چارچوب مدیریت ریسک هوش مصنوعی NIST بر پایش رفتار سامانه در محیط عملیاتی، ثبت نتیجه‌ی ارزیابی در شرایط شبیه استفاده‌ی واقعی و روشن بودن مسئولیت‌ها در همکاری انسان و هوش مصنوعی تأکید می‌کند. این‌ها شرط‌های مفیدی برای توافق خدمت‌اند؛ چون اطمینان را به گردش‌کار زنده وصل می‌کنند.

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

ظرفیت، هزینه و بازبینی انسانی را کنار هم بودجه‌بندی کنید

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

خدمت هوش مصنوعی علاوه بر ظرفیت معمول، تعداد توکن‌ها، سقف درخواست ارائه‌دهنده، فراخوانی طولانی ابزار و هزینه‌ی متغیر استنتاج را هم وارد محاسبه می‌کند. پلتفرم داده با پنجره‌ی دسته‌ای، هم‌زمانی انبار داده و بار بازپردازش روبه‌روست. تأیید انسانی هم به شیفت، سقف صف، مهارت بازبین و خستگی کارکنان وابسته است.

بازبینی انسانی را زیاد به‌عنوان حفاظ معرفی می‌کنیم، اما در بودجه طوری با آن رفتار می‌شود که انگار رایگان است و ظرفیتش هیچ‌وقت تمام نمی‌شود. در توافق روشن کنید:

• چه نوع موردهایی حتماً بازبین انسانی می‌خواهند؛
• بازبین چه شواهدی می‌بیند؛
• نرخ معمول و اوجِ ورود درخواست چقدر است؛
• برای هر سطح شدت چه زمان پاسخی لازم است؛
• چه کسی نیروی پشتیبان فراهم می‌کند؛
• با عبور صف از حد امن چه اتفاقی می‌افتد.

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

قابلیت اطمینان بالاتر هزینه دارد. راهنمای کنونی مایکروسافت درباره‌ی بده‌بستان‌های قابلیت اطمینان هزینه‌ی عملیاتی را روشن می‌کند: افزونگی، مشاهده‌پذیری، تمرین، مستندسازی و آماده‌باش همگی پول یا توجه می‌خواهند. هدف خدمت باید با ارزشی که مسیر کاربریِ مورد حمایت دارد تناسب داشته باشد. بیش‌ازحد مهندسی کردن گزارش داخلی کم‌اهمیت، همان‌قدر نادرست است که کم‌توجهی به جریان پرداخت مشتری.

به همین دلیل حفظ قابلیت اطمینان هنگام تحویل سریع‌تر هوش مصنوعی تا حد زیادی به ظرفیت برمی‌گردد. تیم باید برای ارزیابی، نگهداری، واکنش به رخداد و بازیابی وقت داشته باشد؛ نه این‌که همه‌ی ظرفیتش صرف افزودن قابلیت شود.

مسیر ارجاع را با تصمیم تعریف کنید، نه فقط شماره‌ی تماس

بخشی که در توافق فقط اسم و شماره تلفن دارد کامل نیست. به آدم‌ها می‌گوید مزاحم چه کسی شوند، اما نمی‌گوید آن فرد چه اختیاری دارد.

برای هر وضعیت نقض توافق، این موارد را تعیین کنید:

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

سه زمان را از هم جدا کنید. زمان تشخیص یعنی چقدر طول می‌کشد متوجه وضعیت شویم. زمان تصمیم یعنی سازمان چقدر طول می‌دهد تا واکنش را تأیید کند. زمان بازیابی یعنی چقدر طول می‌کشد مسیر کاریِ قابل‌قبولی دوباره در دسترس باشد. بعضی تیم‌ها زمان بازیابی را بهینه می‌کنند، اما درباره‌ی دو مورد اول چیزی روشن نمی‌گویند.

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

یک نمونه‌ی چندلایه را قدم‌به‌قدم مرور کنید

فرض کنید دستیار داخلی به کارشناسان پشتیبانی کمک می‌کند پاسخ مشتری را بر اساس سیاست‌های شرکت آماده کنند. توافق کاربردی می‌تواند این‌طور خلاصه شود:

این عددها فقط نمونه‌اند و توصیه‌ی همگانی نیستند. حد مناسب به شدت پرونده، تحمل کاربر، رفتارِ آزموده‌شده‌ی سامانه، نیروی انسانی، مقررات و هزینه‌ی شکست بستگی دارد. ارزش جدول این است که برای هر لایه یک تصمیم تعیین می‌کند؛ نمی‌گذارد «API روشن بود» پایان بررسی باشد.

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

وقتی واقعیت تغییر کرد، توافق را بازبینی کنید

ممکن است توافق دیگر با واقعیت جور نباشد، در حالی که همه‌ی تیم‌ها طبق متن قدیمی‌اش کار می‌کنند. ترافیک بالا می‌رود. کاربر پیشنهاد را با تصمیم نهایی اشتباه می‌گیرد. گزارش دسته‌ای به کار روزانه‌ی حیاتی تبدیل می‌شود. ارائه‌دهنده‌ی مدل عوض می‌شود، منبع داده جابه‌جا می‌شود یا بازبینی انسانی دو برابر حجم پیش‌بینی‌شده درخواست می‌گیرد. شاید هم دستیارِ کم‌خطر اجازه‌ی نوشتن و تغییر پیدا کند.

علاوه بر تقویم سالانه، نشانه‌هایی تعریف کنید که بررسی دوباره را فعال کنند:

• تغییر مهم در حجم کار، گروه کاربر، جغرافیا یا ساعت خدمت؛
• ورود فروشنده، مدل، ابزار، منبع داده یا مجوز تازه؛
• نقض مکرر هدف یا وقوع حادثه‌ی نزدیک به آسیب؛
• تغییر پایدار در هزینه‌ی هر نتیجه‌ی موفق؛
• طبقه‌بندی تازه‌ی ریسک حقوقی، امنیتی یا اثر بر کسب‌وکار؛
• شواهدی که نشان می‌دهد کاربران بیش از وعده‌ی نوشته‌شده به سرویس وابسته‌اند.

در بازبینی، متن توافق را با استفاده‌ی مشاهده‌شده‌ی سرویس مقایسه کنید. شاخص‌هایی را که دیگر تصمیمی را تغییر نمی‌دهند کنار بگذارید. هدف را فقط وقتی سخت‌تر کنید که سود کاربر هزینه‌ی عملیاتی را توجیه کند. اگر شواهد نشان داد نمی‌توانید دامنه‌ی فعلی را صادقانه پشتیبانی کنید، وعده را محدود کنید یا به سطح واقع‌بینانه‌تری برگردانید.

نسخه‌ی توافق، داشبورد، راهنمای عملیات و نقشه‌ی وابستگی‌ها را کنار هم نسخه‌بندی کنید. هدفی که به پرس‌وجوی اندازه‌گیریِ قدیمی اشاره کند از نداشتن هدف بدتر است؛ چون اطمینان می‌دهد، اما کنترلی ایجاد نمی‌کند.

پیش از امضا این ده پرسش را بپرسید

پیش از تأیید توافق سطح خدمت، از نماینده‌ی ارائه‌دهنده و مصرف‌کننده بخواهید بدون نگاه به نوشته به این پرسش‌ها پاسخ دهند:

• کدام مسیر کاریِ کاربر تحت حمایت است؟
• چه حجم و بازه‌ی زمانی‌ای در دامنه‌ی توافق است؟
• موفقیت را از کجا اندازه می‌گیریم؟
• هدف چیست و طی چه مدتی سنجیده می‌شود؟
• هر طرف چه کاری باید انجام دهد؟
• سرویس چه ظرفیتی را می‌تواند پشتیبانی کند؟
• کدام وابستگی زودتر از بقیه ممکن است مسیر کاربر را خراب کند؟
• بلافاصله پس از عبور از حد چه می‌شود؟
• چه کسی اختیار کاهش قابلیت یا توقف سرویس را دارد؟
• چه تغییری بررسی دوباره را الزامی می‌کند؟

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

توافق سطح خدمتِ مفید لزوماً سخت‌گیرانه‌ترین سند یا سندِ پُر از معیار نیست. باید کمک کند پیش از رخداد، هنگام فشار بیش از ظرفیت، پس از خرابی فروشنده و با تغییر سرویس، تصمیمی دشوار بگیریم.

تعهد را حول نتیجه‌ی کاربر بنویسید. از مسیر کاربر اندازه بگیریدش. مسئولیت هر وابستگی را روشن کنید. ظرفیت لازم—از جمله ظرفیت انسانی—را فراهم کنید و مشخص کنید نرسیدن به هدف چه چیزی را تغییر می‌دهد. بعد متن توافق را با سرویسی که مردم واقعاً استفاده می‌کنند همگام نگه دارید.