https://virgool.io/SahabPardaz/feed محلی برای به اشتراک‌گذاری دانش و تجربیات مهندسین نرم‌افزار سحاب fa 2026-06-16 09:05:25 https://files.virgool.io/upload/publication/33fmkl2vvoyo/91u7xc.png https://virgool.io/SahabPardaz https://virgool.io/SahabPardaz/%D8%AE%D9%84%D8%A7%D8%B5%D9%87%D9%94-%DA%A9%D8%AA%D8%A7%D8%A8-%D9%BE%D8%B1%D9%88%DA%98%D9%87-%D9%82%D9%82%D9%86%D9%88%D8%B3-yiyofgwzgrbx جلد کتاب پروژه ققنوس 1 معرفیپروژه ققنوس توسط جین کیم[1]، کوین بر[2] و جورج اسپفورد[3]، سه نفر از رهبران فکری جنبش DevOps نوشته شده و در چند سال گذشته بسیار محبوب گشته است. این کتاب در قالب یک رمان به رشتهٔ تحریر درآمده که باعث می‌شود خواندن آن بسیار سرگرم‌کننده‌تر از خواندن بسیاری از کتاب‌های حرفه‌ای در این زمینه باشد.پروژهٔ ققنوس با پیونددادن موضوعات میان‌رشته‌ای مختلف، راهی جذاب برای ظهور توانایی فناوری اطلاعات در کمک به رشد کسب‌وکارها به خواننده نشان می‌دهد. کتاب در رساندن این مفهوم بسیار عالی عمل کرده است و مفاهیم مختلفی را از زمینه‌های متفاوت به‌صورت منسجم، ترکیب می‌نماید. پروژهٔ ققنوس همچنین راهی سرگرم‌کننده برای یادگیری نحوهٔ بهبود فرایند کسب‌وکار و تحول فرهنگی در شرکت‌های بر پایهٔ فناوری اطلاعات است.نوبودن این کتاب در بیان این ایده‌ها برای نخستین بار نیست. این ایده‌ها دهه‌ها قبل بیان شده و در عمل کارایی خود را در مسیر تولید در کارخانجات، رهبری، فرهنگ ایمنی، امنیت، عملیات فناوری اطلاعات و مهندسی نرم‌افزار نشان داده بودند؛ بااین‌حال هیچ‌وقت اینقدر هنرمندانه به هم پیوند داده نشده بودند.دلیل محبوبیت این کتاب این است که با استفاده از مفاهیم آن می‌توان به هر سازمان مبنی‌بر فناوری اطلاعات کمک کرد تا با حفظ کیفیت، سرعت عملکرد خود را بسیار افزایش دهد. دست‌یابی به این مهم بسیار سخت بوده ولی دارای مزایای تجاری عظیمی خواهد بود. همچنین سبب ایجاد فرهنگی خواهد شد که بیشتر ما آرزوی داشتن آن را در هر سازمانی داریم.2 خلاصهٔ داستانروایت کتاب حول شخصیت یک مدیر IT به نام بیل پالمر[4] می‌چرخد که کارمند یک شرکت قدیمی تولیدکنندهٔ قطعات خودرو به نام Parts Unlimited است. داستان از این قرار است که شکست فاجعه‌بار دیگری در بخش فناوری اطلاعات شرکت باعث اخراج غیررسمی مدیران مافوق سابق بیل شده و وی ناگهان به سِمَت معاونت فناوری اطلاعات[5] سوق داده می‌شود. بیل سابقه خوبی در به‌نتیجه‌رساندن کارها به‌کمک استفادهٔ عملی از روال‌ها و هدایت عالی یک گروه کوچک از پرسنل را دارد. استیو مسترز[6]، مدیر عامل Parts Unlimited از بیل می‌خواهد تا به هرج‌ومرج در دپارتمان ITپایان دهد. باتوجه‌به افت قیمت سهام شرکت، تیتراخبارشدن شکست‌های شرکت و نمایش توانایی رقبا در نوآوری زودبه‌زودتر و کسب مشتریان بیشتر، وضعیت برای بیل بسیار وخیم به نظر می‌رسد. وی با اکراه این چالش را قبول می‌کند تا به نجات شرکت کمک کند.طیف گسترده‌ای از شخصیت‌ها در این داستان وجود دارند که به‌احتمال‌زیاد خواننده را به یاد همکارانی – و یا حتی خودش – می‌اندازد که وضعیت کاری مشابهی دارند. تیم مدیریتی بیل از وز[7] و پتی[8] تشکیل شده است. وز مدیر پرانرژی سیستم‌های توزیع‌شده بوده و پتی[9] که بسیار در اجرای فرایندها جدی است، مدیر سرویس خدمات IT می باشد. همچنین چند مدیر ارشد در شرکت دارای قدرت می‌باشند و بیل آرام‌آرام درمی‌یابد که باید برای درک و پاسخ به نیاز آن‌ها سخت کار کند. شخصیت دیگر داستان برنت[10]، مهندس عملیات فوق‌العاده‌ای است که به‌دلیل نبوغ و دانش عمیقش پیرامون IT، در حیاتی‌ترین فرایندهای IT شرکت نقش اساسی دارد.مشکلاتی که این شخصیت‌ها در طول داستان به آن برمی‌خورند، حتی آشناتر از تیپ این شخصیت‌هاست. درست مانند دنیای واقعی، ساختار سازمانی ضعیف، بدهی فنی و سیستم‌های به‌شدت به‌هم‌وابسته و درهم‌تنیده، بسیاری از این مشکلات را ایجاد می‌کنند. و باز هم درست مانند دنیای واقعی، خلاصی از این مشکلات، چالش‌برانگیز است؛ زیرا نیاز به سطح بالایی از خلاقیت، پشتکار و همکاری دارد.دراین‌میان یکی از شخصیت‌های محوری داستان، دکتر اریک رید[11]، یکی از اعضای هیئت مدیره Parts Unlimitedاست که کاراکتری عجیب‌وغریب و تاثیرگذار دارد. با مربی‌گری بیل و دیگر همکارانش توسط اریک، به‌تدریج آشکار می‌گردد که وی دارای دانش عمیقی از IT و مهندسی سیستم‌ها است. در لحظات کلیدی، اریک مفاهیم جدیدی را معرفی می‌کند که بیل را قادر می‌سازد از آن‌ها در تلاش‌های خود برای جلوگیری از سقوط به‌ظاهر اجتناب‌ناپذیر شرکت استفاده کند.این رمان، بسیار خواندنی است؛ بنابراین روال تعریف ادامهٔ داستان را در اینجا متوقف کرده و درعوض به مفاهیم زیربنایی کتاب خواهیم پرداخت.3 مفاهیمکتاب پروژهٔ ققنوس، مقدمهٔ فوق‌العاده‌ای برای چندین مفهوم کلیدی است. برای درک عمیق این مفاهیم، پیشنهاد می‌شود که متن کامل کتاب و مخصوصاً مطالب اضافی انتهای کتاب را خودتان مطالعه کنید و این متن را بیشتر به‌عنوان یک مرجع برای آشنایی اولیه با این مفاهیم در نظر بگیرید.1-3 کارهای چهارگانهاریک با بردن بیل به یک بازدید، شروع به معرفی چهار نوع کار IT می‌کند. بیل سه نوع اول را به‌نسبت سریع درک می‌کند ولی درک نوع چهارم برایش کاری دشوار است؛ تا‌این‌که ماهیت مشکل‌زای نوع چهارم در جریان تغییر عادت‌های کاری تیم، خود را نشان می‌دهد.نوع اول کار، پروژه‌های کسب‌وکاری هستند. این نوع کارها، فرایندهای کسب‌وکار می‌باشند که معمولاً شامل ایجاد ویژگی‌های جدید با هدف ارائهٔ قابلیت یا افزایش کارایی موردنیاز مشتریانند. کارهای نوع اول توسط رهبران کسب‌وکار به پیش رانده می‌شوند و می‌توانند به‌عنوان پروژه‌هایی در شرکت تعریف شده و اهرم پیش‌راننده آن‌ها معمولاً مدیران داخل‌سازمانی می‌باشند که به نظرشان انجام آن کار، سرمایه‌گذاری مفیدی برای شرکت می‌باشد.نوع دوم کار، پروژه‌های داخلی بخش IT هستند. این‌ها عمدتاً کارهای روزمرهٔ کوچک‌تری هستند که در طول زمان روی هم انباشته می‌شوند: نگهداری و به‌روزرسانی سیستم‌های موجود، بازنشسته‌کردن فناوری‌های قدیمی، اعمال وصله‌های امنیتی و غیره. این‌قبیل کارها، باعث می‌شوند شرکت سرپا بماند و می‌توانند برنامه‌ریزی شده و در صف کارها قرار بگیرند.تغییرات، سومین نوع کار می‌باشند که شامل رفع باگ‌ها، به‌روزرسانی نسخه‌ها و هر بهبودی هستند که از دل کارهای نوع اول و دوم ایجاد می‌شوند. این‌ها به‌روزرسانی‌ها و پشتیبانی‌های روتینی هستند که به‌علت وجود برنامه‌ها و زیرساخت‌های مختلف ایجاد می‌شوند.چهارمین و مضرترین نوع کار، کارهای پیش‌بینی‌نشده می‌باشند. این کارها باعث می‌شوند باقی کارها دوباره انجام شوند؛ زیرا انواع برنامه‌ریزی‌ها را به آشوب کشیده و مختل می‌کنند. کارهای پیش‌بینی‌نشده به‌شدت موذی و نامرئی هستند و انجام سایر تعهدات برنامه‌ریزی‌شده را ناممکن می‌نمایند؛ زیرا باعث کندی یا مسدودشدن روال دیگر انواع کار هستند. به‌دلیل تاثیر مخرب آن‌ها بر سه نوع دیگر، باید به‌هرقیمتی از آن‌ها اجتناب کرد.هدف از معرفی این کارهای چهارگانه این است که برای بیل روشن شود که قابل‌دیدن‌کردن کارها، اولین گام برای شروع درک درست هر کاری است. اگر جزئیات روال‌های کاری داخل سازمان درک نشوند، نمی‌توان آن‌ها را برنامه‌ریزی کرد و مطمئن بود که اولویت‌های درون و بیرون سازمان به‌درستی دیده می‌شوند.2-3 کار در جریان[12]اریک به بیل می‌آموزد که کار در جریان (WIP) یکی از دلایل اصلی مشکلات مزمن در تحویل محصول و کیفیت آن است. عدم کنترل WIPمنجر به مرگ تدریجی و اجتناب‌ناپذیر بهره‌وری در سازمان خواهد شد.پروژهٔ ققنوس، اثباتی است از این که چگونه مفاهیمی مانند تولید ناب[13] یا سیستم تولید تویوتا بسیار بیشتر از آن چیزی که متخصصین مهندسی نرم‌افزار فکر می‌کنند به توسعهٔ نرم‌افزار ارتباط دارد. درحال‌حاضر نسلی از مهندسین نرم‌افزار این ایده‌ها را پذیرفته‌اند و از نظر بهره‌وری و کیفیت، دستاوردهای قابل‌توجهی داشته‌اند. بسیاری از متدولوژی‌های توسعه نرم‌افزار چابک مانند اسکرام نیز این مفاهیم را در دل خود جا داده‌اند.داشتن WIP به تمرکز یا عدم وجود آن خلاصه می‌شود؛ بدین‌معنی‌که به‌جای این که به‌صورت همزمان روی چند موضوع کار کنید، در یک زمان فقط روی یک کار تمرکز کنید و آن را خوب انجام دهید. بدین‌ترتیب اشتباهات کم‌تری اتفاق می‌افتند و بنابراین کارهای کم‌تری باید دوباره انجام شوند. هر اقدامی که باید تکرار شود، اضافه‌کاری تلقی می‌شود؛ زیرا باعث می‌شود کار اول را دور بریزیم. تفکر ناب حول این ایده شکل گرفته است که سازمان‌ها باید دائماً این اضافه‌کاری‌ها را کاهش دهند تا منابع ذخیره‌شده ازاین‌طریق صرف دیگر موضوعات مانند کارامدترکردن فرایندها، بهبود ابزارها و روال‌ها و انجام تست برای خلق ویژگی‌ها یا محصولات جدید شوند.کتاب پروژهٔ ققنوس فقط لایهٔ رویی تفکر ناب را آشکار می‌کند؛ زیرا تنها اعمال این اقدامات را در توسعه نرم‌افزار نشان می‌دهد.3-3 بردهای کانبان[14]درنهایت بیل و همکارانش با ایجاد کانبان برای تیم‌های خود با اثرات WIPبیش‌ازحد مقابله کرده و درنتیجه کارهای خود را قابل‌مشاهده می‌کنند. این موضوع به آن‌ها اجازه می‌دهد که کارهای خود را اولویت‌بندی کرده و به باارزش‌ترین آن‌ها بپردازند. به‌طورخاص، زمان برنت به‌شدت زیر ذره‌بین قرار می‌گیرد تا او بتواند همواره روی کاری با بالاترین اولویت تمرکز کند.کانبان در زبان ژاپنی به‌معنای بیلبوردکانبان در زبان ژاپنی به معنای «بیلبورد» است. ایدهٔ اصلی آن، ایجاد یک بورد است که تمام قسمت‌های روال شما به‌ترتیب در ستون‌های آن علامت‌گذاری شده‌اند. هر کار به‌وسیلهٔ یک کارت نشان داده می‌شود که مربوط به شخص یا اشخاص مسئول آن کار می‌باشد. با اتمام یک قسمت از کار، کارت آن، یک ستون جلوتر می‌رود تا هنگامی که به ستون «تکمیل‌شده‌ها» برسد.مثالی از بورد کانبانمفهوم اصلی کانبان این است که قابل‌مشاهده‌کردن هر کار به تیم اجازه می‌دهد که تصویر کلی مراحل انجام آن کار را در یک نما ببیند؛ بدین‌ترتیب روند پیگیری فرایندها بسیار آسان شده، همکاری بهتری ایجاد و WIP بسیار واضح می‌گردد.4-3 ده استقرار در روزبا افزایش بهره‌وری و بهبود خط‌لوله توسعه، تیم Parts Unlimited به جایی می‌رسد که می‌تواند بسیار سریع‌تر از بازه‌های سه‌ماهه‌ای که با آن شروع کرده بود، نسخه جدید ارائه کند؛ اگرچه ده نسخه در روز هنوز برای تیم دورازدسترس به نظر می‌رسد. درنهایت، آن‌ها آرام‌آرام متوجه می‌شوند که ارائه نسخه‌های جدید با سرعت بیشتر اما با تغییرات کوچک‌تر، توان عملیاتی شرکت را بیشینه کرده و انعطاف‌پذیری لازم را برای پاسخگویی سریع به درخواست مشتریان عملی می‌سازد.«ده استقرار در روز» یکی از شعارهای معروف جنبش DevOps است. این شعار به توانایی اعمال تغییرات در تولید، با تواتر چندین بار در روز به‌جای سه‌ماهه، ماهیانه و یا هفتگی اشاره می‌کند. اگرچه قرار نیست سرعت اعمال تغییرات به‌معنای واقعی کلمه این مقدار باشد؛ ولی این شعار نشان‌دهندهٔ امکان رسیدن به یک سرعت رقابتی مناسب است. شرکت‌های یونیکورن مانند آمازون و گوگل، مشهور به انتشار با فرکانس هزاران یا صدهاهزار بار در روز هستند.یک نکتهٔ ظریف این است که این شعار لزوماً به معنای استقرار واقعی نیست؛ بلکه به معنای توانایی آن می‌باشد. استقرار مداوم ممکن است همواره همراه با ویژگی‌های جدید نباشد؛ اما رفع اشکال یا وصله‌های حیاتی، انواع به‌روزرسانی‌هایی هستند که باید به‌سرعت و بدون ایجاد مشکل برای سایر قسمت‌ها، در سیستم اعمال شوند.به‌طورکلی، پروژهٔ ققنوس این مفهوم را با ظرافت تمام با نمایش مشکلاتی نشان می‌دهد که در راه رسیدن به چنین اهدافی در تقابل بین تعهد به رسیدن به «ده استقرار در روز» و داشتن پروسهٔ روان برای دست‌یابی به آن بروز می‌کنند.5-3 نظریه محدودیت‌هاتا زمانی که بیل شروع به درک نظریهٔ محدودیت‌ها[15]نکرده است، نمی‌تواند سازمان را در جهت درست هدایت کند. این عدم توانایی به این دلیل است که تا وقتی که بسیاری از اقدامات اصلاحی گروه او فقط موقتی هستند - بدون تغییر در نحوه کار سازمان، همان مشکلات دوباره دیریازود رخ خواهند داد.آن‌ها با اعمال نظریهٔ محدودیت‌ها، تنگناهای واقعی سیستم را شناسایی کرده و شیوه‌ها و فرایندهایی را برای بهبود مستمر جریان کار و اتخاذ رویکردی با استراتژی بهتر معرفی می کنند.نظریهٔ محدودیت‌ها به فرایند شناسایی و حذف مستمر تنگناها در هر سیستم معین اشاره دارد. برای این کار، باید درک درستی از خود سیستم به دست آورد. این به معنای درک هر مرحله از فرایند است. از آنجا که این مراحل اغلب در ضمیر افراد پنهان شده است، این کار برخلاف ظاهر ساده آن، بسیار دشوار می‌باشد. تا زمانی که این مراحل به‌ترتیب، فهرست، درک و ترسیم نشده باشند، ایجاد یک فرایند تکرارپذیر که ثبات و کیفیت لازم را ایجاد کند، به‌راحتی قابل دستیابی نیست.معمولاً عملی به نام نقشه‌برداری جریان ارزش[16]، اولین گام در اعمال نظریهٔ محدودیت‌هاست. این دقیقاً همان چیزی است که بیل و همکارانش برای درک جریان کار از آن استفاده کردند. با این نقشه‌برداری، آن‌ها توانستند به اندازهٔ کافی نقاط انسداد سیستم را برطرف سازند و بدین‌ترتیب جریان کار را تسریع کنند.6-3 استفاده از راه‌های سه‌گانهاریک بخش زیادی از کتاب را صرف راهنمایی بیل برای درک و به کارگیری راه‌های سه‌گانه می‌کند؛ مدلی که نقطهٔ قوت کتاب پروژهٔ ققنوس است.به گفته یکی از نویسندگان، راه‌های سه‌گانه عبارتند از:... اصولی که همهٔ الگوهای DevOps را می‌توان از آن‌ها استخراج کرد، که هم در کتاب «راهنمای DevOps[17]» و هم در کتاب «پروژهٔ ققنوس: رمانی درباره IT، DevOps، و کمک به پیروزی کسب‌وکار شما» استفاده می‌کنیم. ما ادعا می‌کنیم که راه‌های سه‌گانه، ارزش‌ها و فلسفه‌هایی را توصیف می‌کنند که فرایندها، روال‌ها، عملکردهای DevOps و همچنین مراحل اثبات‌شده در طول زمان را چارچوب می‌دهند.برای درک این مدل تصور کنید هر کاری، از آغازبه‌کار تا تحویل محصول نهایی، به عنوان یک‌سری مراحل از چپ به راست جریان دارد. این «کار» به‌معنای تحویل یک ارزش به مشتریان می‌باشد. مفهوم «ارزش» نیز موارد مختلفی را در بر می‌گیرد: می‌تواند یک برنامه، یک سرویس یا یک محصول فیزیکی باشد - اساساً، هر چیزی که مشتری آن را مفید قلمداد کند. این جریان ازچپ‌به‌راست، به عنوان جریان ارزش نامیده می‌شود.راه‌های سه‌گانه روشی است برای بیشینه‌کردن ارزش تحویلی از طریق بهینه‌سازی فرایند رساندن ارزش به مشتری، به‌دست‌آوردن بینش سریع‌تر و عمیق‌تر با قراردادن مکانیسم‌های نظارتی، و بهبود و خلق ارزش‌های جدید از طریق آزمایش.راه‌های سه‌گانه را می‌توان به‌این‌صورت بیان کرد:1. راه اول - به طور مداوم راه‌هایی برای بهبود تحویل پیدا کرده و اجرا کنید. این مترادف با مفهوم کایزن[18]است.2. راه دوم - به‌سرعت بازخورد دریافت کنید و به‌گونه‌ای کار کنید که اگر در ابتدا بازخوردهایی درباره مشکلات بزرگ دارید، پس از مدتی و با حل آن‌ها به بازخوردهایی درباره مشکلات کوچک‌تر و کوچک‌تر برسید تا درنهایت به وضعیت دریافت بازخوردهای مشکلات درمورد کیفیت محصول دست یابید.3. راه سوم - از کارایی ناشی از راه اول و بدون‌باگ‌بودن منتج از راه دوم استفاده کنید تا جهت خلق دستاوردهای کیفی، برای هر چیزی دست به آزمایش فوری آن بزنید.ایدهٔ اصلی این است که با پیروی از راه‌های سه‌گانه، شرکت شما به‌مراتب از رقبا پیشی گرفته و با خلق ارزش برای مشتریان، سهم بیشتری از بازار را به خود اختصاص خواهد داد.4 نتیجه‌گیریدرهم‌تنیدگی و تحت‌یک‌مدل‌ذهنی‌درآوردن چنین ایده‌هایی برای اولین بار در کتاب پروژهٔ ققنوس انجام گرفت. این مدل توضیح می‌دهد که این ایده‌ها هر کدام چه هدفی دارند و چگونه به هم مربوطند. قبل از نگارش این کتاب، ایده‌های مطرح‌شده در آن وجود داشتند ولی هیچ‌وقت به‌صورتی یک‌جا بیان نشده بودند که چنین جذابیتی داشته باشند.به‌علاوه کتاب به‌گونه‌ای نوشته شده است که تمام شخصیت‌ها، موقعیت‌ها و انتخاب‌ها برای خواننده آشنا به نظر برسد. این نحوهٔ نوشتن باعث می‌شود خواننده بتواند ارتباط عمیقی با آموزه‌های کتاب برقرار کند؛ زیرا قصهٔ کتاب، یک داستان ساده نیست؛ بلکه یک درام است که با روایت نحوهٔ کار گروهی شخصیت‌ها برای فرار از پرتگاه سقوط، خواننده را وارد یک رابطه احساسی و حس همدردی با آن‌ها می‌کند.در مجموع، کتاب پروژهٔ ققنوس یک مقدمهٔ عالی برای مفاهیم DevOps است. این کتاب می‌تواند به هر فرد حرفه‌ای درگیر در جنبه‌های مختلف فناوری اطلاعات کمک کند که بفهمد یک سازمان مبتنی بر فناوری اطلاعات چگونه باید کار کند و تصویر کلی‌تری از آن را ببیند.[1] Gene Kim[2] Kevin Behr[3] George Spafford[4] Bill Palmer[5] VP of IT[6] Steve Masters[7] Wes[8] Patty[9] Patty[10] Brent[11] Dr Eric Reid[12] Work in Process (WIP)[13] Lean manufacturing[14] Kanban Boards[15] The Theory of Constraints (TOC)[16] Value-Stream Mapping[17] DevOps Handbook[18] 改善 تِک‌بلاگ سحاب سلمان Thu, 24 Mar 2022 19:35:33 +0430 https://virgool.io/SahabPardaz/isolation-forest-r2vxodzrakxd با گسترش فناوری‌های انفورماتیک، دامنهٔ فعالیت مدیران محصول نیز روز به‌ روز توسعه و تنوع بیشتری می‌یابد. امروزه در اکثر شرکت‌های مطرح نرم‌افزاری و تحلیل داده به‌خصوص آن‌هایی که محصولات لبهٔ علم تولید می‌کنند، موقعیت شغلی AI/ML Product Manager و Data Product Manager ایجاد شده است و این افراد به‌ صورت مستقیم بر فرایندهای یادگیری ماشین و هوش مصنوعی موجود در توسعهٔ محصول نظارت دارند. در این مقاله قصد داریم کمی در علوم داده عمیق‌تر شویم و با یک الگوریتم نسبتا جدید و کاربردی در زمینهٔ شناسایی داده‌های پرت و ناهنجار آشنا شویم.در تحلیل‌های آماری شناسایی ناهنجاری‌ها و یافتن نقاط پرت (Outlier Points) اهمیت بسیار زیادی دارد. در بعضی موارد وجود این نقاط باعث ایجاد خطا در طراحی مدل‌ آماری شده و دقت پیش‌بینی انجام شده را به طرز محسوسی کاهش می‌دهد. مواردی نیز وجود دارد که این نقاط نشانگر بروز نفوذ و فعالیت غیرعادی کاربران است که با بررسی آن‌ می‌توان امنیت سیستم را افزایش داد.در علم آمار، ناهنجاری یک مشاهدهٔ نامتعارف، رویداد یا مقداری است که اختلاف و انحراف قابل توجهی نسبت به سایر مقادیر و رفتار متفاوتی نسبت به دیگر نقاط داشته باشد. به طور مثال در میان توپ‌های غمگین، یک توپ خوشحال یک مشاهدهٔ ناهنجار و نامتعارف به حساب می‌آید.نقاط ناهنجار می‌توانند معانی متفاوتی داشته باشند. به طور مثال نمودار زیر نشان‌دهندهٔ ترافیک ورودی یک وب‌سایت است که بر اساس تعداد درخواست‌ها در بازه‌ی زمانی سه‌ ساعته در مدت‌ زمان یک ماه به تصویر کشیده است.در نگاه اول کاملا مشخص است که برخی از نقاط (دور آن‌ها دایره قرمز کشیده شده است) به طور غیرمعمولی بزرگ‌تر از دیگر مقادیر هستند. یعنی در آن بازهٔ زمانی درخواست‌هایی که سمت سرور وب‌سایت ارسال شده، افزایش قابل توجهی داشته است. با توجه به اینکه این درخواست‌ها به شکل مقطعی هستند و در زیر خود سطح تشکیل نداده‌اند، این‌طور به نظر می‌رسد که سرور در آن زمان مورد حمله DDos (حمله محروم‌سازی از سرویس) قرار گرفته است. البته حالت‌های احتمالاتی دیگری نظیر وجود جشنواره‌های فروش ویژه و ... را نیز می‌توان در نظر گرفت که موجب شده در یک مدت زمان اندک تعداد زیادی درخواست ارسال شود. همچنین قسمت مسطح این نمودار نیز احتمالا نشانه‌ی وجود اشکال و اختلال در عملکرد سرور است؛ چرا‌که در آن بازهٔ زمانی هیچ درخواستی دریافت نشده است.بدیهی است که شناسایی ناهنجاری‌ها و نقاط پرت تمام مجموعه‌های داده به همین سادگی امکان‌پذیر نیست و در مواردی، به‌خصوص زمانی که با مجموعه‌هایی از جنس کلان‌داده روبه‌رو هستیم، شناسایی نقاط پرت کار بسیار پیچیده‌ای است و نیازمند استفاده از الگوریتم‌های هوشمند است.روش‌های آماری متعددی برای شناسایی ناهنجاری‌ها وجود دارد که در این مقاله به بررسی الگوریتم جنگل ایزوله (Isolation Forest Algorithm) می‌پردازیم که یکی از به‌روزترین‌ و کاربردی‌ترین الگوریتم‌های علوم داده در حوزهٔ شناسایی ناهنجاری‌ها و یافتن نقاط پرت است.پیدایش الگوریتم جنگل ایزولهدر سال ۲۰۰۸ سه دانشمند علوم کامپیوتر به نام‌های «فی تونی لیو»، «کای مینگ تینگ» و «ژوی هوآ ژو» برای اولین بار الگوریتم جنگل ایزوله (به اختصار iForest) را ابداع کردند. ایده‌ی اصلی آن‌ها برای طراحی این الگوریتم دو ویژگی متداول داده‌های پرت و ناهنجار بود که عبارتند از:کم بودن تعداد این نقاط نسبت به سایر نقاطتفاوت چشمگیر مقادیر این نقاط نسبت به توده‌ی کلی (هنجار) داده‌ها از آن‌جایی که ناهنجاری‌ها تعدادشان کم و مقادیرشان متفاوت است، جداسازی و دسته‌بندی آن‌ها در مقایسه با نقاط هنجار آسان‌تر است. راهکار کلی الگوریتم جنگل ایزوله این است که گروه‌هایی از «درختان جداسازی» (Isolation Trees) در مجموعه‌ی داده ایجاد کند. بدین ترتیب ناهنجاری‌ها نقاطی هستند که به‌طور میانگین مسیر کوتاه‌تری نسبت به دیگر نقاط در «درختان جداسازی» دارند. لازم به ذکر است که نویسندگان مقاله «درختان جداسازی» را به اختصار iTrees و الگوریتم جنگل ایزوله را iForest نام‌گذاری کرده‌اند.در سال ۲۰۱۰ افزونه‌ای از این الگوریتم به نام SCiforest با تمرکز بر بررسی مباحث ناهنجاری‌های خوشه‌ای و به کارگیری از اَبرصفحه‌های تصادفی به منظور افزایش توانایی تشخیص ناهنجاری‌های موازی منتشر شد. این توانمندی‌ها در نسخهٔ اولیه این الگوریتم وجود نداشت. کمی بعدتر در سال ۲۰۱۲ نویسندگان نسخهٔ اولیه مقاله «الگوریتم جنگل ایزوله» مجموعه‌ای از آزمایش‌ها را طراحی کردند تا ثابت کنند iForest دارای ویژگی‌های زیر است:پیچیدگی زمانی اندکی دارد و برای اجرا شدن حافظهٔ کمی از دستگاه را اشغال می‌کند.قابل استفاده در داده‌های بزرگ با ویژگی‌های غیرمرتبط است.الگوریتم قابلیت یادگیری و آموزش را دارد.بدون نیاز به آموزش مجدد، توانایی ارائهٔ نتایج تشخیص با سطوح مختلف دسته‌بندی را دارد.در سال ۲۰۱۳ دو دانشمند علوم کامپیوتر به نام «ژینگو دینگ» و «مینوری فی» ساختاری را بر مبنای iForest طراحی کردند که در آن مشکل تشخیص ناهنجاری‌ها در جریان داده‌ها (streaming data) برطرف شده بود. این اتفاق نقطهٔ عطفی در توسعهٔ الگوریتم iForest به حساب می‌آمد، چرا که اکنون بسیاری از سیستم‌های کلان‌‌داده‌ای نیز می‌توانستند از این الگوریتم برای شناسایی نقاط ناهنجار و پرت استفاده کنند و همین امر سرعت انجام تحلیل‌های آتی این جنس از داده‌ها و انجام فعالیت‌هایی نظیر «داده کاوی» و «یادگیری ماشین» را به طور محسوسی افزایش می‌داد.زیر میز بزنید!احتمالا انسان‌ها پیش از آن که با مفهومی به نام علوم داده و تحلیل‌های آماری آشنا شوند، به صورت ناخودآگاه الگوسازی از نقاط هنجار را انجام می‌دادند. متداول‌ترین شیوه‌ای که برای شناسایی نقاط ناهنجاری استفاده می‌شود استفاده از الگوریتم الگوسازی (Profiling) است. در این شیوه الگوریتم با تحلیل تمام اعضای مجموعهٔ داده، یک الگو از نقاط عادی می‌سازد و داده‌هایی که تفاوت معناداری با نقاط عادی دارند را به عنوان نقاط پرت و ناهنجار شناسایی می‌کند. این در حالی است که الگوریتم جنگل ایزوله یا همان iForest با شیوه‌ی متفاوتی این‌گونه نقاط را مورد شناسایی و بررسی قرار می‌دهد.الگوریتم iForest به جای آن‌که برای ساختن یک مدل نرمال تلاش کند، ابتدا نقاط غیرعادی و ناهنجار را شناسایی و از مجموعهٔ داده جدا می‌کند. این الگوریتم در ابتدا یک ویژگی (یک بُعد) را به صورت تصادفی انتخاب می‌کند و سپس یک مقدار تصادفی در فاصلهٔ بین کمینه و بیشینهٔ مجموعهٔ داده انتخاب کرده و با یک خط جداساز آن بُعد را جدا می‌کند. بدین ترتیب یک مجموعهٔ درخت ایجاد می‌شود و درخت‌هایی که طول کمتری دارند به عنوان دادهٔ پرت و ناهنجاری شناسایی می‌شوند. لازم به ذکر است که iForest یک الگوریتم یادگیری بدون نظارت (Unsupervised Learning) به حساب می‌آید. در بخش بعدی مقاله با نحوهٔ فعالیت این الگوریتم بیشتر آشنا خواهیم شد.جنگل ایزوله زیر ذره‌بینهمان‌ طور که در بخش قبلی اشاره شد، رهیافت متداول در شناسایی ناهنجاری، الگوسازی از نقاط نرمال بود؛ اما iForest رویکرد متفاوتی را در پیش گرفته است. ایده‌ی اصلی الگوریتم این است که اگر بر روی مجموعهٔ داده یک درخت تصمیم‌گیری رسم شود، نقاط ناهنجاری طول کوتاه‌تری دارند و به ریشه نزدیک‌تر هستند.برای فهم بهتر این مفهوم با یک مثال ساده شروع می‌کنیم؛ حدودا نزدیک به ۸ میلیارد انسان بر روی کرهٔ زمین وجود دارند و آن‌ها را به عنوان یک مجموعهٔ داده در نظر می‌گیریم. این مجموعهٔ داده را می‌توان به بُعد‌هایی نظیر سن، دارایی، محل تولد، موقعیت شغلی و ... تقسیم‌بندی کرد. حال می‌خواهیم در این مجموعه‌ی داده نقاط ناهنجار را شناسایی کنیم. دقت کنید که نقاط ناهنجار لزوما داده‌های اشتباهی نیستند و تنها تفاوتی معنادار با دیگر نقاط دارند. رسم درخت تصمیم‌گیری را با بُعد «برخورداری از دارایی ۱۷۰ میلیارد دلاری» آغاز می‌کنیم.در این درخت تصمیم‌گیری «جف بزوس» بنیان‌گذار شرکت آمازون به عنوان یک نقطهٔ نامتعارف شناسایی می شود. با توجه به شکل مشخص است که او به ریشهٔ درخت بسیار نزدیک است. البته که این درخت تصمیم‌گیری هرس نشده است و احتمالا نقاط ناهنجاری دیگری نیز دارد.برای ایزوله کردن درخت جف بزوس، تنها کافی است این سوال را بپرسید که «آیا او بیش از ۱۷۰ میلیارد دلار دارایی دارد؟» اما از آن جایی که شخص جلیل علیزاده (نویسندهٔ مقاله) بسیار معمولی‌تر از جف بزوس است، برای ایزوله کردن او حداقل نیاز به پرسیدن ۱۰ سوال بله/خیر دارید.حال بهتر است به سراغ یک مثال آماری‌تر برویم و مجموعه‌ای از داده‌ها را در مختصات دو بعدی x-y قرار بدهیم. این مجموعه داده را ابتدا از طریق یک بُعد (خط آبی) جداسازی می‌کنیم، سپس جداسازی با بُعد دوم (خط نارنجی) صورت می‌گیرد و در نهایت آخرین جداسازی (خط سبز) انجام می‌شود.اگر بخواهیم این مجموعهٔ داده ‌را به صورت درخت تصمیم‌گیری رسم کنیم، شکل زیر حاصل می‌شود. همان‌طور که مشخص است نقطهٔ G کوتاه‌ترین طول مسیر (طول مسیر برابر ۱) را دارد و از همه نقاط دیگر به ریشه نزدیک‌تر است و به همین منظور نقطهٔ G یک ناهنجاری و داده پرت به حساب می‌آید. در این شکل به طور مثال نقطهٔ C طول مسیرش برابر ۳ است و بنابراین ناهنجاری نیست.برای تولید یک جنگل ایزوله باید تعداد زیادی درخت ساخته شود و هر درخت مشخص می‌کند که کدام نقاط زودتر ایزوله می‌شوند که در حقیقت نقاط ناهنجار هستند. در نهایت پس از رسم درخت‌ها به هر نقطه یک امتیاز بین ۰ تا ۱ داده می‌شود.، هر میزان امتیاز ناهنجاری به ۱ نزدیک‌تر باشد، این نقطه به احتمال بیشتری یک دادهٔ پرت و ناهنجار است. در بحث بعدی به صورت متمرکزتر به بررسی نحوهٔ محاسبهٔ نمره ناهنجاری می‌پردازیم.ویژگی‌های اصلی جنگل ایزولهاکنون نگاهی به ویژگی‌های کلی iForest می‌اندازیم و نکات مثبت و منفی آن را مورد بررسی قرار می‌دهیم:زیرنمونه‌گیری (Sub-sampling): با توجه به اینکه الگوریتم iForest نیازی به یافتن و جداسازی همهٔ نقاط نرمال ندارد، این الگوریتم می‌تواند توده‌ی عظیمی از نقاط نمونه‌ی آموزشی را نادیده بگیرد. بنابراین می‌توان ادعا کرد که iForest هنگامی که اندازهٔ نمونه کوچک نگه داشته شود، عملکرد بسیار خوب و دقت بالایی دارد. این ویژگی در میان دیگر الگوریتم‌ها کمتر دیده می‌شود.غرق شدن(Swamping): هنگامی که فاصلهٔ میان نقاط نرمال و نقاط ناهنجار بسیار کم باشد، تعداد درخت‌های موردنیاز برای جداسازی ناهنجاری‌ها افزایش می‌یابد. در این شرایط ممکن است پدیده‌ای به نام «غرق شدن» رخ دهد. این امر سبب می‌شود که iForest تفاوت میان نقاط ناهنجار و نرمال را به کندی و با اشتباه فراوان تشخیص دهد. بنابراین ممکن است با هر بار اجرای الگوریتم، نقاط متفاوتی به عنوان ناهنجاری شناسایی شوند و همین امر باعث می‌شود تا دقت الگوریتم به طرز محسوسی کاهش پیدا کند.پوشیده ماندن(Masking): زمانی که تعداد ناهنجاری‌ها زیاد باشد، این احتمال وجود دارد که برخی از نقاط در یک خوشه متراکم و بزرگ قرار بگیرند و جداسازی ناهنجاری‌ها توسط iForest بسیار سخت و دشوار شود. این امر شباهت‌های زیادی با پدیدهٔ «غرق شدن» دارد و با انجام کارهایی نظیر نمونه‌گیری فرعی می‌توان مشکل را برطرف کرد.داده‌های کلان‌بُعدی(High Dimensional Data): یکی از جدی‌ترین محدودیت‌های روش استاندارد که بر مبنای محاسبهٔ تابع فاصله کار می‌کند، ناکارآمدی الگوریتم در مواجه با مجموعه‌ٔ داده‌های کلان‌بُعدی است. در فضاهای کلان‌بُعدی، فواصل نقاط نسبت به یکدیگر تقریبا یکسان است و همین امر اندازه‌گیری مبتنی بر فاصله را عملا ناکارآمد می‌کند. بدیهی است که الگوریتم iForest نیز در مواجه با این شکل از داده‌ها عملکرد ضعیفی دارد، اما با اضافه کردن یک آزمون و انتخاب ویژگی‌های محدود می‌توان باعث افزایش دقت و عملکرد الگوریتم شد.محاسبه نمره ناهنجاریاستراتژی محاسبه نمره ناهنجاری یک نقطه، براساس معادل‌سازی مشاهدهٔ ساختاری iTrees با ساختار درختی جست‌وجوی دودویی (Binary Search Trees) است. این سخن بدین معنا است که رسیدن به یک گره خارجی از iTree برابر با یک جست‌وجوی ناموفق در BST است. بنابراین محاسبهٔ میانگین طول مسیر که همان h(x) است برای رسیدن به یک گره خارجی از فرمول زیر به‌دست می‌آید:در این رابطه n تعداد داده‌های آزمایشی، m حجم نمونه و H عدد هارمونیک است که از رابطهٔ زیر به‌دست می‌آید:همچنین γ برابر با «ثابت اویلر-ماسکرونی» است که به صورت تقریبی برابر با ۰.۵۷۷ است. همان‌طور که اشاره شد مقدار c(m) میانگین h(x) است که برحسب m نوشته شده است. بنابراین با انجام یک فرایند نرمال‌سازی می‌توانیم مقدار نمرهٔ ناهنجاری را با توجه به x و m به‌دست آوریم که برابر است با:در این رابطه E(h(x)) امید ریاضی است که برابر با مقدار میانگین h(x) بر روی مجموعه درختان iTree است. اکنون با به‌دست آوردن این رابطه می‌توانیم حالت‌بندی‌های زیر را انجام دهیم:اگر مقدار s به ۱ میل کند، آن‌گاه می‌توان گفت که نقطهٔ x یک ناهنجاری است.اگر مقدار s به ۰.۵ میل کند، آن‌گاه می‌توان گفت که نقطهٔ x یک نقطه نرمال و متعارف است.اگر به‌ازای همه مقادیر x مقدار s به ۰.۵ میل کند، می‌توان گفت که مجموعه‌ٔ داده مذکور فاقد ناهنجاری است و تمام نقاط آن متعارف و نرمال هستند.رفع مشکل نمره ناهنجاری توسط یک ایرانییکی از اصلی‌ترین مشکلات نسخهٔ اولیه الگوریتم iForest محاسبهٔ «نمرهٔ ناهنجاری» بود. این ایراد در سال ۲۰۱۸ توسط سه دانشمند علوم کامپیوتر به نام‌های «سهند حریری»، «ماتیاس کاراسکو» و «رابرت برنر» در دانشگاه ایلینوی (University of Illinois) برطرف شد. این افراد مدل جدیدی به نام «جنگل ایزوله توسعه یافته» (Extended Isolation Forest) یا به اختصار EIF را ارائه کردند. این الگوریتم محاسبهٔ نمره ناهنجاری را با دقت بیشتری انجام می‌دهد.پیاده‌سازی جنگل ایزوله در پایتوندر این مرحله یک مثال از پیاده‌سازی جنگل ایزوله در پایتون را بررسی می‌کنیم. به منظور سادگی کار یک مجموعه داده دوبعدی را مورد بررسی قرار می‌دهیم. در گام اول نیاز است که مقداری داده تولید کنیم و تمرکز بیشتری بر روی داده‌های نرمال بگذاریم که به‌عنوان مجموعهٔ داده آموزشی استفاده می‌شود. روند آموزش داده و امتیازدهی ناهنجاری استفاده شده را از scikit-learn استخراج کرده‌ایم. در نهایت خواهیم داشت:# importing libaries ---- import numpy as np import pandas as pd import matplotlib.pyplot as plt from pylab import savefig from sklearn.ensemble import IsolationForest# Generating data ---- rng = np.random.RandomState(42) # Generating training data X_train = 0.2 * rng.randn(1000, 2) X_train = np.r_[X_train + 3, X_train] X_train = pd.DataFrame(X_train, columns = ['x1', 'x2']) # Generating new, 'normal' observation X_test = 0.2 * rng.randn(200, 2) X_test = np.r_[X_test + 3, X_test] X_test = pd.DataFrame(X_test, columns = ['x1', 'x2']) # Generating outliers X_outliers = rng.uniform(low=-1, high=5, size=(50, 2)) X_outliers = pd.DataFrame(X_outliers, columns = ['x1', 'x2'مجموعه داده تولیدشده در شکل زیر قابل مشاهده است. همان گونه که در نظر داشتیم، داده‌های نرمال که به عنوان مجموعه داده آموزشی مورد استفاده قرار گرفته بودند، در کنار هم هستند. این در حالی است که داده‌های پرت به صورت پراکنده هستند.اکنون باید جنگل ایزوله را آموزش دهیم. در فرایند آموزش‌ دادن، متغیر «آلودگی» را برابر با ۰.۱ قرار دهیم که همان مقدار پیش‌فرض scikit-learn است.# Isolation Forest ---- # training the model clf = IsolationForest(max_samples=100, random_state=rng) clf.fit(X_train) # predictions y_pred_train = clf.predict(X_train) y_pred_test = clf.predict(X_test) y_pred_outliers = clf.predict(X_outliers)اکنون که الگوریتم کار پیش‌بینی و شناسایی داده‌های ناهنجار را ادامه داده است. دنبال آن هستیم که عملکرد iForest را در شناسایی داده‌های پرت بررسی کنیم. بنابراین به شکل زیر عمل می‌کنیم:# new, 'normal' observations ---- print(&quotAccuracy:&quot, list(y_pred_test).count(1)/y_pred_test.shape[0]) # Accuracy: 0.93# outliers ---- print(&quotAccuracy:&quot, list(y_pred_outliers).count(-1)/y_pred_outliers.shape[0]) # Accuracy: 0.96در نگاه اول این‌طور به نظر می‌رسد که عملکرد الگوریتم بسیار خوب و شناسایی نقاط ناهنجار با دقت بالایی انجام شده است. تنها نکته‌ای که وجود دارد این است که تعدادی از داده‌های پرت که به صورت تصادفی ایجاد شده‌اند در ناحیهٔ هنجار و نرمال قرار گرفته‌اند، اما همچنان به عنوان ناهنجاری و داده پرت شناسایی شده‌اند. برای افزایش دقت و کاهش خطاهای این‌چنینی می‌توانیم تغییراتی در متغیرهایی نظیر؛ آلودگی، تعداد تخمین‌گرها و ... ایجاد کنیم و بار دیگر خروجی را بررسی کنیم. با این حال نتایج خروجی به‌دست آمده کاملا رضایت‌بخش است.استفاده از کاربرد جنگل ایزوله در سُکانجمع‌آوری داده‌های فروش مشتریان و ارائهٔ تحلیل‌ و گزارش‌های متنوع مبتنی بر این داده‌ها یکی از مهم‌ترین فرایندهایی است که در محصول سکان رخ می‌دهد. بدیهی است که برای انجام تحلیل‌ دقیق‌تر نیاز است تا داده‌های ناهنجار و نامتعارف شناسایی و از مجموعهٔ دادهٔ نهایی حذف شوند تا دقت خروجی افزایش داشته باشد. به همین دلیل تیم فنی سکان اقدام به طراحی و توسعهٔ یک ماژول شناسایی ناهنجاری کرده است. یکی از الگوریتم‌های به کار رفته در توسعه این ماژول iForest است که با دقت و عملکرد قابل‌قبولی به شناسایی ناهنجاری‌ها و داده‌های نامتعارف می‌پردازد. از این ماژول شناسایی ناهنجاری در بخش‌های مختلفی از محصول سکان نظیر انجام تحلیل RFM و پیش‌بینی ریزش استفاده می‌شود. تِک‌بلاگ سحاب جلیل علیزاده Sat, 05 Mar 2022 12:27:02 +0330 https://virgool.io/SahabPardaz/%D9%87%D8%B1-%D8%A2%D9%86%DA%86%D9%87-%DA%A9%D9%87-%D8%A8%D8%A7%DB%8C%D8%AF-%D8%AF%D8%B1%D9%85%D9%88%D8%B1%D8%AF-service-worker-%D9%88-web-worker-%D9%87%D8%A7-%D8%A8%D8%AF%D8%A7%D9%86%DB%8C%D8%AF-dzzps6vimtsq شاید شما هم در مورد قابلیت جدید ورکرها (Worker) که به مرورگرها اضافه شده است شنیده باشید. در این مقاله تلاش می‌کنیم نگاهی دقیق‌تر به این قابلیت داشته باشیم.شما می‌توانید با استفاده از ورکر‌ها قابلیت چندرشته‌ای را (multi thread) را درون مرورگرتان داشته باشید ولی شاید این چند‌رشته‌ای با چند‌رشته‌ای‌های دیگری که در زبان‌های برنامه‌نویسی دیگر مشاهده کرده‌اید متفاوت باشد. زیرا در بسیاری از زبان‌ها ساختار چند‌رشته‌ای به‌صورتی است که شما چند رشته‌ی مختلف را اجرا می‌کنید و همه‌ی این رشته‌ها به توابع و ابجکت‌های (Object) مشترکی دسترسی دارند که مسائلی و مشکلاتی را ایجاد می‌کند و برنامه‌نویس باید مراقب استفاده از آن‌ها باشد تا کلاس‌ها و توابعش thread-safe باشند و به مشکلی برخورد نکنند. این در حالی ست که ورکر‌ها در جاوااسکریپت به ابجکت‌های non-thread-safe دسترسی ندارند (مانند DOM ها) و انتقال اطلاعات بین این ورکر‌ها نیز فقط توسط ابجکت‌های قابل serialize شدن ردوبدل می‌شود و بصورت انتقال کامل یا کپی کردن صورت می‌گیرد. این بدان معناست که نمی‌توان ابجکت‌ها را بین ورکر‌ها به اشتراک گذاشت که باعث می‌شود همه چیز thread-safe باشد.حالا که دانستیم ورکر برای چیست و چه محدودیت‌هایی دارد بهتر است با هم سری به کد بزنیم.برای ساخت یک ورکر جدید به شکل زیر عمل می‌کنیم. (ورکرها را می‌توان در رشته اصلی و یا ورکرهای دیگر ساخت.)var myWorker = new Worker('worker.js');همانطور که می‌بینید برای ساخت یک ورکر کافی است سازنده (constructor) آن را با آدرس یک فایل اسکریپت (script) اجرا کنیم تا ورکر شروع به دانلود و اجرای آن اسکریپت کند.برای ارتباط میان رشته اصلی (main) و ورکر به این شکل عمل می‌شود که برای ارسال پیام از تابع postMessage استفاده می‌شود و برای دریافت پیام نیز بر روی رخداد message گوش خواهیم داد.// main script var myWorker = new Worker('worker.js'); myWorker.postMessage([first.value, second.value]); myWorker. = function(e) { result.textContent = e.data; console.log('Message received from worker'); }// worker.js self. = function(e) { console.log('Message received from main script'); var workerResult = 'Result: ' + (e.data[0] * e.data[1]); console.log('Posting message back to main script'); self.postMessage(workerResult); }همانطور که در بالا قابل مشاهده است در اسکریپت اصلی با استفاده از ابجکت myWorker پیام‌ها ارسال و دریافت می‌شد در حالی که در اسکریپت ورکر self برای اشاره به ورکر به کار می‌رود.پس از آنکه کارتان با ورکر موردنظر تمام شد نیاز است تا به کار آن خاتمه دهید که با دستور زیر قابل انجام است. myWorker.terminate()ورکرها انواع مختلفی همچون DedicatedWorker ، SharedWorker و ServiceWorker دارند، در SharedWorker ها ورکر ساخته‌شده می‌تواند در بین چند worker/window/iframe به طور اشتراکی استفاده شود در حالی که DedicatedWorker فقط در جایی که ساخته شده است قابل استفاده است. در بالا ما از DedicatedWorker استفاده کردیم ولی قواعد کلی برای SharedWorker ها نیز برقرار است.در صورتی که استفاده از message ها برای شما خوش‌آیند نیست، لایبرری‌های جالبی تلاش برای پیاده‌سازی API های موردپسندتری برای توسعه‌دهنگان کرده‌اند که از میان آن‌ها می‌توان به catiline اشاره کرد.در ادامه نگاهی دقیق‌تر به سرویس ورکر (Service Worker) خواهیم داشت.سرویس ورکر نوع خاصی از ورکر است که می‌تواند رابط بین سایت ما و مرورگر باشد. این ورکر می‌تواند وظایفی را که نیاز به رابط کاربری user-interface ندارد به‌صورت پس‌زمینه (background) انجام دهد. همچنین با توجه به آنکه اجرای آن نیازمند یک پنجره‌ی فعال از سایت شما نیست، مرورگر می‌تواند حتی در صورت بسته بودن تمام پنجره‌ها نیز در صورت نیاز با این ورکر صحبت کند و درخواست‌هایی را برای ما انجام دهد.برای مثال قابلیت هایی که با استفاده از سرویس ورکر می‌توانیم به آن‌ها دست یابیم شامل:- offline-experiences : باز شدن و استفاده از نرم‌افزار تحت وب بدون داشتن اینترنت- background-syncs :‌ انجام برخی عملیات‌های همگام‌سازی در پس‌زمینه- push notifications : دریافت و نمایش اعلان از سرور بدون نیاز به باز بودن سایتبه‌صورت کلی بیشتر رفتارهای این ورکر همانند ورکرهای عادی با استفاده از , postMessage است ولی این ورکر می‌تواند به عنوان network proxy نیز عمل کند و با استفاده از رخداد onfetch به درخواست‌های صادر شده از سایت جواب دهد. همچنین می‌تواند عملیات‌هایی همچون caching نیز انجام دهد.چرخه ی عمر :با اجرای دستور زیر می‌توانید سرویس ورکر خود را نصب کنید و پس از آن با باز شدن پنجره‌های جدید از سایت شما و یا ریلود شدن پنجره‌های فعلی کنترل آن‌ها با سرویس ورکر نصب شده خواهد بود.if ('serviceWorker' in navigator) { window.addEventListener('load', function () { navigator.serviceWorker.register('/sw.js').then( function (registration) { // Registration was successful console.log('ServiceWorker registration successful'); }, function (err) { // registration failed :( console.log('ServiceWorker registration failed'); }, ); }); }چرخه ی عمر سرویس ورکرهمانطور که در نمودار بالا مشاهده می‌کنید در صورتی که نصب سرویس ورکر شما موفقیت‌آمیز باشد پس از آن سرویس ورکر به حالت idle می‌رود و در صورتی که درخواستی با message و یا fetch نداشته باشد برای کاهش مصرف رم (RAM) متوقف می‌شود و تمامی متغیرهای محلی آن از حافظه‌ی رم پاک می‌شوند. به همین علت لازم است در صورتی که می‌خواهید دیتایی (Data) رو در بین ری‌استارت‌های مختلف نگهداری کنید لازم است که آن ها را در IndexedDB ذخیره کنید و سپس در استارت بعدی مقادیر مورد نیاز را از آن بخوانید.برای مشاهده‌ی لیست سرویس ورکر‌های نصب‌شده در مرورگرتان می‌توانید به آدرس chrome://inspect/#service-workers مراجعه کنید.در کد سرویس ورکر می‌توانید با دریافت رخداد install مراحل نصبی که مورد نظرتان است شامل cache کردن فایل های استاتیک و یا کارهای دیگر را انجام دهید. self.addEventListener('install', function(event) { const promise = doInstallSteps(); event.waitUntil(promise); });در قطعه‌کد بالا از تابع waitUntil استفاده شده است. وظیفه‌ی این تابع دریافت کردن یک promise می‌باشد تا متوقف شدن سرویس ورکر را تا زمان به نتیجه رسیدن پرامیس موردنظر به تاخیر بیاندازد.برای مدیریت راحت‌تر cache و offline-experience می‌توانید از لایبرری workbox استفاده نمایید.از رخدادهای مهم دیگر موجود در سرویس ورکر می‌توان به push و notificationclick برای دریافت اطلاعات از سرور به‌صورت push و نمایش اعلان و مدیریت دکمه‌های قابل مشاهده در اعلان و sync برای ارسال اطلاعات به سرور حتی پس از بسته شدن پنجره‌ی سایت اشاره کرد.منابع و مطالعه‌ی بیشتر :توضیحات وب‌ورکر در سایت MDNتوضیحات سرویس ورکر در سایت developers.google تِک‌بلاگ سحاب محمدحسین اله‌دادیان Sat, 12 Feb 2022 13:39:35 +0330 https://virgool.io/SahabPardaz/%D9%85%D9%87%D9%86%D8%AF%D8%B3%DB%8C-%D8%AF%D8%A7%D8%AF%D9%87-%D8%A7%D8%B2-%D8%AD%D8%B1%D9%81-%D8%AA%D8%A7-%D8%B9%D9%85%D9%84-xp3delvitzap استفاده از ابزارها و فریم‌ورک‌های مختلف بدون اینکه درک عمیقی از پشت‌صحنه وجود داشته باشد شاید برای انجام یک کار در اندازهٔ کوچک یا متوسط کافی باشد. ولی قطعا برای انجام یک کار در اندازهٔ بزرگ با وجود شاخصه‌هایی مثل قابلیت اطمینان (Reliability)، مقیاس‌پذیری (Scalability) و قابلیت نگهداری (Maintainability) کافی نیست. اینجاست که باید درک عمیقی از پشت‌صحنهٔ ابزارها و فریم‌ورک‌ها داشته باشیم تا بتوانیم ابزار مناسب را انتخاب کنیم و بدانیم در شرایط مختلف به چه شکل عمل می کنند و اصلا چه تنظیماتی باید به چه شکل انجام شود تا از ابزار انتخابی به بهترین شکل استفاده کنیم. این مسئله در دنیای پردازش داده‌های حجیم با توجه به پیچیدگی‌های ذاتی پردازش توزیع‌شده و تنوع ابزارهای موردنیاز با شدت بیشتری وجود دارد.مهندسی داده (Data Engineering) یک عنوان شغلی نسبتا جدید است که هدفش طراحی و پیاده‌سازی پایپ‌لاین‌های دریافت، ذخیره‌سازی، آماده‌سازی و بازیابی داده‌ها با هدف تسهیل امکان اجرای پردازش‌های تحلیلی پیچیده بر روی داده است. مطالعات متعددی در سطح بین‌المللی نشان داده که جایگاه شغلی مهندس داده به لحاظ نرخ رشد و همچنین سطح پرداخت‌ها، در رتبهٔ نخست جایگاه‌های شغلی قرار دارد:طبیعتا طراحی پایپ‌لاین‌های داده و عملا معماری محصول، متناسب با ویژگی‌های مسئله متفاوت است و اولین مرحله، طراحی معماری سیستم است. در طراحی معماری سیستم باید دانش کافی در مورد انواع مدل‌های پردازشی و ذخیره‌سازی و بازیابی داده و همچنین شناخت درستی از نیازمندی‌ها و ویژگی‌های مسئله موردنظر وجود داشته باشد:· حجم داده‌ها، نرخ ورود و تنوع آن به چه شکل است و کجا و به چه شکل باید به صورت موقت یا دائمی ذخیره شود؟· چه تضمینی در مورد داده‌ها نیاز است؟ سازگاری داده (Data Consistency) تا چه حد مهم است؟ دسترس‌پذیری (Availability) چطور؟· ازدست‌رفتن یک داده چقدر اهمیت دارد؟· کش کردن داده نیاز است یا نه؟· برای ذخیره‌سازی از پایگاه داده‌های رابطه‌ای (Relational Database) استفاده شود یا بر پایهٔ سند (Document-Based) یا فایل سیستم توزیعی؟· نیاز به پردازش جریانی (Stream Processing) وجود دارد یا پردازش دسته‌ای (Batch Processing) یا هر دو؟· و ...بر اساس این معیارها باید نوع مولفه‌ها در معماری یک سیستم داده‌ای انتخاب شود.در مرحلهٔ بعد برای پیاده‌سازی بخش‌های مختلف، متناسب با معماری طراحی‌شده از ابزارهای مختلفی استفاده می‌شود. عوامل زیادی در انتخاب ابزار برای هر بخش تاثیر‌گذار است. از وجود نیروی انسانی متخصص گرفته تا انطباق با نیاز ما.مرحلهٔ بعد پیکربندی ابزار است. عموما تعداد پارامترهای قابل تنظیم ابزارهای داده خیلی زیاد است. برای استفاده‌های دم‌دستی معمولا تنظیمات پیش فرض به‌خوبی کار می‌کند و کافی است. برای استفادهٔ حرفه‌ای و در مقیاس بزرگ از یک ابزار، باید معماری آن را بشناسیم و از پشت‌صحنهٔ آن مطلع باشیم، تنظیمات اصلی را بدانیم و بر اساس صورت مساله‌ای که داریم پیکربندی را انجام دهیم.با توجه به مواردی که تا اینجا گفته شده است، برای اینکه بتوانیم معماری درستی طراحی کنیم، انتخاب‌های درست برای نوع مولفه‌ها در معماری داشته باشیم، ابزار درستی برای هر مولفه معماری انتخاب کنیم، ابزار را به نحو مناسب پیکربندی کنیم و در نهایت در مواجهه با مشکلات و باگ‌ها بتوانیم مشکلات را برطرف کنیم باید دید خوبی نسبت به پایه‌های دانشی سیستم‌های داده‌ای توزیع شده داشته باشیم. حال که به نظر می‌رسد نیاز است پشت‌صحنه را تا حد خوبی بدانیم و عمیق شویم، این سوال مطرح می شود که از کجا شروع کنیم.معرفی کتابکتابی که قصد داریم در این مطلب معرفی کنیم دقیقا در این جایگاه قرار دارد و قصد دارد شما را با مفاهیم و چالش‌ها و مزایا و معایب انواع پیاده‌سازی بخش‌های زیرساختی یک سیستم داده‌ای آشنا کند. عنوان کتاب طراحی برنامه‌های داده‌محور (Designing Data-Intensive Applications) با زیرعنوان «ایده‌های اصلی پشت سیستم‌های قابل اطمینان، مقیاس پذیر و با قابلیت نگهداری بالا» است. نویسندهٰ این کتاب آقای مارتین کلپمن استاد دانشگاه کمبریج انگلستان است و کتاب در سال ۲۰۱۷ منتشر شده است. این کتاب از سه بخش کلی تشکیل شده است. بخش اول کتاب به بیان مفاهیم پایه‌ای سیستم‌های داده می‌پردازد. در بخش دوم مباحث مرتبط با توزیع‌شدگی ارائه شده است. در نهایت در بخش سوم هم معماری کلی سیستم‌های داده بیان شده است.در بخش اول کتاب بعد از شرح دقیق قابلیت اطمینان، مقیاس‌پذیری و قابلیت نگهداری به بیان مدل‌های داده و زبان‌های پرس‌و‌جوی داده‌ها پرداخته شده است. در ادامه، بحث ذخیره‌سازی و بازیابی داده با بیانی گام‌به‌گام و با شروع از مفاهیم پایه‌ای ذخیره‌گاه داده (Data Storage) و مقایسهٔ انواع پایگاه دادهٔ رابطه‌ای و بر پایهٔ سند، بحث را تا طراحی انبارهٔ داده (Data Warehouse) و ذخیره‌سازی ستونی (Columnar Storage) پیش برده است. با خواندن این فصل عملا دید خوبی در خصوص انواع ذخیره‌گاه‌های داده و مفاهیم پایه‌ای آن‌ها به‌ دست می آید. در نهایت در فصل پایانی این بخش بحث کدگذاری (Encoding) و سریال‌سازی اشیا داده‌ای بیان شده است.یکی از نکات خوب این کتاب این است که پس از توضیح روش‌های مختلف پیاده‌سازی یک مفهوم مثل ذخیره‌گاه داده، گریزی به ابزارهای معروف زده شده است و این نکته به درک پشت‌صحنه ابزارهای مرسوم کمک کرده و در انتخاب ابزار مناسب نیز به ما کمک می‌کند. مثلا فرض کنید در فرآیند طراحی معماری به این نتیجه رسیده‌ایم که به یک پایگاه داده NoSQL نیاز داریم. توجه کنید که مفاهیم مرتبط با انواع پایگاه داده و تفاوت‌های اصلی آن‌ها در بخش اول کتاب بیان شده است. در مرحلهٔ بعد باید ابزار مناسب را انتخاب کنیم. دو نمونهٔ اصلی از ذخیره‌گاه‌ها برای داده‌های حجیم HBase و Cassandra است که در بخش اول کتاب و در بحث ذخیره‌سازی مطرح شده است. این پایگاه‌های داده، داده‌ها را در قالب کلید-مقدار ذخیره می‌کنند و ذخیره و بازیابی بر اساس کلید با سرعت بالا انجام می‌شود. مثلا فرض کنید برای یک مسئله به این نتیجه می‌رسیم که باید قابلیت جستجو روی بعضی از فیلدهای مقدار داشته باشیم. طبیعتا اگر حجم داده خیلی زیاد باشد نمی‌توانیم داده‌ها را چند بار ذخیره کنیم و هر بار یکی از فیلدها را کلید قرار دهیم. یعنی عملا بهتر است امکانی مثل اندیس‌گذاری (Index) روی برخی از فیلدهای مقدار داشته باشیم. در این حالت به جای گزینه‌هایی مثل HBase می‌توانیم از Cassandra که اندیس ثانویه (Secondary Index) را پشتیبانی می‌کند استفاده کنیم. البته توجه کنید که در حالت کلی باید مسئله را از ابعاد مختلف تحلیل و بررسی کنیم.بخش دوم کتاب در مورد داده‌های توزیع‌شده است. رونوشت‌برداری (Replication) و چندپاره کردن (Partitioning) و انواع روش‌های مرسوم و چالش‌های مربوطه در فصل‌های اول و دوم این بخش ارائه شده است. تقریبا می‌توان گفت که رونوشت‌برداری و چندپاره کردن در اغلب سیستم‌های داده‌ای توزیع‌شده (از Kafka گرفته تا HBase و HDFS , …) وجود دارد و مسیر به سمت مقیاس‌پذیری، دسترس‌پذیری بالا و تحمل‌پذیری خطا (Fault-Tolerance) از این مفاهیم گذر می‌کند. در ادامهٔ این بخش از کتاب بحث تراکنش‌ها مطرح شده است. اگر قصد دارید خواص ACID (Atomicity, Consistency, Isolation, Durability) پایگاه داده را عمیق درک کنید حتما این فصل را مطالعه کنید. نکتهٔ قابل توجهی که در این فصل بیان شده است این است که Isolation و Consistency و Durability سطوح مختلفی دارد و برخلاف تصور اولیه که مثلا پایگاه داده‌های رابطه‌ای مرسوم ACID را به صورت کامل پشتیبانی می‌کنند و پیش‌فرض اولیهٔ انواع پایگاه داده رابطه‌ای است، باید به صورت دقیق‌تر گفت که به عنوان مثال سطوحی از Isolation را پشتیبانی می‌کنند و عموما قابل تنظیم است. در فصل بعدی مشکلات متداول در سیستم‌های توزیع‌شده مثل بحث توافق و همگام شدن زمان سیستم‌ها و غیرقابل‌اطمینان بودن شبکه مطرح شده است و در نهایت در فصل آخر این بخش از کتاب مسئلهٔ سازگاری و اجماع (Consensus) بیان شده است و سطوح سازگاری و همچنین چالش‌هایی که در رسیدن به اجماع در سیستم‌های توزیع شده وجود دارد مطرح شده است.شاید شنیده باشید که طبق تئوری CAP(Consistency, Availability, Partitioning)، در یک سیستم توزیع‌شده همزمان دو مورد از این موارد می‌تواند وجود داشته باشد. با توجه به اینکه از دوپاره شدن شبکه نمی‌توان جلوگیری کرد در نتیجه یا باید سیستم به سمت سازگاری برود یا اینکه دسترس‌پذیری را انتخاب کنیم. به عنوان مثال ابزار HBase به سمت CP متمایل است و Cassandra به سمت AP. نکته‌ای که قابل توجه است این است که بدانیم وقتی ابزاری AP است یا CP به چه معنی است. مثلا AP یعنی اینکه کلا سازگاری داده را در این ابزار نداریم؟ باید بدانیم که سازگاری سطوحی دارد و قابل تنظیم است. کلا دنیا دنیای مصالحه است. باید یک چیز داده شود تا چیز دیگری به دست آید. یا حداقل باید از یک مورد کمتر بخواهیم تا از مورد دیگر بیشتر داشته باشیم. توضیح دقیق این مفاهیم در بخش دوم کتاب بیان شده است.در نهایت در بخش سوم کتاب به بحث تجمیع سیستم‌های مختلف داده‌ای (انواع مختلف ذخیره‌سازی موقت و دائمی، پردازش دسته‌ای و جریانی) در جهت ایجاد یک سیستم با یک معماری یکپارچه پرداخته شده است. در فصل اول از این بخش، پردازش دسته‌ای و مدل پردازشی Map-Reduce مورد بحث قرار گرفته است و در ادامه در فصل دوم پردازش جریانی ارائه شده است. در نهایت در فصل آخر، آیندهٔ سیستم‌های داده بیان شده و ایده‌هایی برای ساخت برنامه‌هایی قابل اطمینان، مقیاس پذیر و با قابلیت نگهداری بالا مطرح شده است.جمع بندیکتاب معرفی شده در این مطلب برای مهندسین نرم‌افزار که تمایل به ورود به بحث سیستم‌های توزیع‌شده، سیستم‌های با کارایی بالا و در حالت کلی سیستم‌های ذخیره‌سازی و پردازش داده‌های حجیم دارند حاوی مطالب بسیار آموزنده‌ای است. این کتاب علاوه بر بیان مفاهیم بنیادین در سیستم‌های داده‌ای به بیان انواع تصمیم‌های طراحی و معماری سیستم‌های زیرساختی و چالش‌ها و مصالحه‌های موجود در آنها می‌پردازد. از طرف دیگر صحبت در مورد اینکه ابزارهای معروف در این حوزه از چه انتخاب‌های طراحی استفاده کرده‌اند به خواننده در انتخاب ابزار مناسب و پیکربندی‌های مهم متناسب با نیازمندی های مسئله کمک می‌کند. در نهایت خواندن این کتاب را به همهٔ مهندسین نرم‌افزار و علاقمندان به حوزهٔ مهندسی داده توصیه می‌کنم. تِک‌بلاگ سحاب Hamzei Sat, 29 Jan 2022 14:39:49 +0330 https://virgool.io/SahabPardaz/%D8%A8%D9%84%D9%87-%DA%AF%D8%B1%D9%81%D8%AA%D9%86-%D8%A7%D8%B2-%D8%AE%D9%88%D8%AF-pxt60cjkrcwv در این مطلب درباره کتاب «بله گرفتن از خود» می‌خوانیم. ابتدا کمی از نویسنده کتاب بگوییم. ویلیام اوری، یکی از شناخته‌شده‌ترین افراد در زمینه «مذاکره» است. او به عنوان مشاور، در برخی از پرتنش‌ترین مذاکرات با کشورهایی از قبیل شوروی و یوگوسلاوی سابق، چچن، اندونزی و ونزوئلا شرکت داشته است. تجربه‌های او محدود به مشاوره‌های سیاسی نبوده است. او به تدریس فنون مذاکره به رهبران اتحادیه‌های کارگری و مدیران اجرایی شرکت‌های بین‌المللی می‌پردازد و در زمینه مدیریت تنش و اختلاف‌ها از موارد فامیلی گرفته تا انواع اختلافات محلی یا کاری، در قالب کارگاه و مشاوره تجربه دارد. نخستین کتاب او با عنوان «بله گرفتن» که در سال ۱۹۸۱ منتشر شد با استقبال گسترده‌ای مواجه شد و بیش از ۱۳ میلیون نسخه چاپی فروش کرد. پس از آن چندین کتاب دیگر در این زمینه منتشر کرد. کتاب اخیر او با عنوان «بله گرفتن از خود» پس از ۳۵ سال و کسب تجربه‌های بسیار به نوعی نسخه کامل‌تر کتاب «بله گرفتن» به شمار می‌رود. به اعتقاد ویلیام چیزی در کتاب نخست جا افتاده بود که اکنون آن را بهتر می‌شناسد و آن، نگرش به درون است. این که اگر بخواهیم بر دیگران تاثیر بگذاریم نخست باید بر خود تاثیر گذاریم و این که اگر بخواهیم مسیر مذاکره و حل‌و‌فصل اختلاف‌هایمان را با موفقیت طی کنیم باید رابطه‌مان را با خودمان به درستی شکل دهیم. البته باید دقت داشت که این کتاب صرفا در باب مذاکره به معنای خاص آن نیست بلکه می‌توان آموزه‌های آن را در بهبود هر نوعی از تنش‌ها و اختلاف‌ها به کار گرفت.در این کتاب، در ۶ گام این نوع نگرش به درون تشریح می‌شود که در ادامه به اختصار درباره هریک توضیح خواهم داد. در توضیح هر گام سعی کرده‌ام وفادار به نوع نگاه نویسنده باشم تا حتی‌الامکان تصویر صحیحی از آنچه در کتاب به آن پرداخته شده ایجاد کنم. جمع‌بندی و نظرات شخصی‌ام را در بخش مجزایی در انتهای مطلب آورده‌ام.گام اول: خودت را جای خودت بگذاراین را بسیار شنیده‌ایم که خودت را جای دیگری بگذار اما این که خودمان را جای خودمان بگذاریم چه معنی می‌دهد؟ مگر جای خودمان نیستیم؟ مطلب این است که خیلی مواقع ما کارهایی می‌کنیم که به ضررمان عمل می‌کند. نویسنده بارها از این عبارت استفاده می‌کند که «دشمن خودمان نباشیم بلکه متحد خودمان باشیم». در بسیاری مواقع، وقتی ما بر سر فرزند یا دوست و همکار قدیمی خود فریاد می‌زنیم یا با او قطع رابطه می‌کنیم یا به او اهانت می‌کنیم، به نفع خودمان عمل نمی‌کنیم. این باعث نمی‌شود که بهبودی در روابطمان ایجاد شود و برعکس گره اختلاف‌ها را تنگ‌تر می‌کند. پس ضروری است اول ببینیم که چه کاری واقعا به نفع ماست؟ چه هدفی داریم و آرامش و رضایت ما واقعا در چیست؟ از خود بپرسیم واقعا دنبال چه هستیم؟ برخلاف انتظار پاسخ به این سوال‌ها بدیهی نیست و ما را به تامل وا می‌دارد. خصوصا وقتی در لایه‌های نیازها و خواسته‌هایمان عمیق می‌شویم. اما چطور می‌توانیم این کار را بکنیم؟ نویسنده ۳ سرمشق در این زمینه دارد. نخست این که از بالا به خود نگاه کنید. در کتاب اصطلاح «زاویه دید از بالکن» به کار رفته است. این تمرینی است برای اینکه رفتارهای ما صرفا واکنش کنترل نشده به شرایط هیجانی و جو داغ حاکم بر تنش‌ها نباشد. سعی کنیم که کمی فاصله بگیریم. از زاویه دید کسی که به موضوع مسلط‌تر است و در آن غرق نشده است ببینیم. فردی که تحت تاثیر عصبانیت، حسادت یا دیگر هیجان‌ها قدرت واکنش هوشمندانه و منطقی را از دست نداده است.سرمشق دوم این است که همدلانه به خودمان گوش دهیم. این که صرفا خود را به واسطه ضعف‌ها سرزنش کرده و آماج اهانت‌ها و منفی‌بافی‌ها قرار دهیم مشکلی را حل نمی‌کند. اگر بخواهیم به خودمان کمک کنیم باید همانند یک دوست و با حس همدلی به خود گوش دهیم تا واقعا خودمان را بشناسیم. و سرمشق آخر این است که از نیازهای‌مان پرده برداریم. این با عمیق‌شدن در خواسته‌ها و افکارمان حاصل می‌شود. مثالی از کتاب بیاوریم:In my negotiation experience, I find that people usually know their position: I want a 15 percent raise in salary. Often, however, they have not thought deeply about their interests --their underlying needs, desires, concerns, fears, and aspirations: Do they want a raise because they are interested in recognition, or in fairness, or in career development, or in the satisfaction of some material need, or in a combination of these?هر چقدر در باب نیازها و علاقه‌مندی‌ها و نگرانی‌های خود عمیق‌تر شویم گزینه‌های خلاقانه‌ بیشتری برای برآورده کردن آن‌ها خواهیم یافت:The deeper you go in uncovering your underlying needs and interests, the more likely you are to invent creative options that can satisfy your interests. In the case of the raise, for example, if your interest is in recognition, then even if budgetary constraints prevent your boss from giving you as high a raise as you had hoped, you might still be able to meet your interest by obtaining a new title or a prestigious assignment. Uncovering interests opens up new possibilities that you might not have thought of before.دقت کنید اینکه خودمان را جای خودمان بگذاریم در مقابل این نیست که خودمان را جای دیگران بگذاریم بلکه هر دو لازم است. خود را جای خود می‌گذاریم تا بدانیم به دنبال چه هستیم. خود را جای دیگری می‌گذاریم تا بتوانیم به این مقصود برسیم. از طرفی، این که اوضاع را از دید طرف مقابل ببینیم خود در شکل گرفتن آن هدفی که دنبالش هستیم کمک می‌کند. شادی و سلامت دیگران، رضایت و حس خوب ما را هم در پی خواهد داشت و ما در عمق وجود خود از اینکه بتوانیم به دیگران کمک کنیم و مشکلاتشان را حل کنیم لذت می‌بریم. اینجاست که سوال «واقعا دنبال چه هستیم» به شناخت دیگران هم ارتباط پیدا می‌کند.گام دوم: بهترین جایگزین درونی بعدیت را بسازنویسنده، ۳۵ سال قبل از این، در کتاب معروفش «بله گرفتن»، اصطلاح BATNA را معرفی کرده بود که مخفف Best Alternative To a Negotiated Agreement است. این اصطلاح که بعدها شهرت بیشتری یافت، به این معنا است که چنانچه مذاکرات به توافق نرسید بهترین گزینه جایگزین ما چه خواهد بود؟ در آنجا روی بعد بیرونی و مشهود BATNA تکیه می‌شد. به عنوان مثال من دوست دارم اتومبیل رفیقم را بخرم. اگر او حاضر نشد به قیمت متناسبی اتومبیل را به من بفروشد چه می‌کنم؟ در اینجا می‌توانم بهترین گزینه خرید بعدی خودم را مشخص کنم. حدی برای خودم مشخص کنم که بالاترین قیمتی که می‌توانم بپردازم چه مقدار است و اگر گرانتر از چه مقداری بود، بهتر است به سراغ گزینه بعدی بروم. اینکه پیش از تصمیم‌گیری و مذاکره، به BATNA فکر کرده باشم و آن را بدانم باعث می‌شود هنگام بحث و مذاکره، اضطراب کمتری داشته باشم. به هرحال می‌دانم در بدترین حالت چه اتفاقی می‌افتد و خودم را برای آن آماده کرده‌ام. همچنین کمک می‌کند که تصمیم بهتری بگیرم. از قبل تحلیل کرده‌ام که چه مرزهایی برایم قابل قبول است، کجا به نفعم است که نرمش نشان دهم و چه زمانی منطقی است که دست از این گزینه بکشم و به سراغ گزینه بعدی بروم. در این کتاب، نویسنده مفهوم جایگزین درونی یا inner BATNA را مطرح می‌کند. گاهی به سادگی نمی‌توان یک جایگزین جذاب و شدنی یافت. اما جایگزین‌های درونی، انعطاف بیشتری دارد و دایره انتخاب‌ها را وسیع‌تر می‌کند. بسیاری را می‌بینیم که گزینه جایگزینی برای خود نمی‌سازند، نتیجه‌ای در ذهن دارند و تنها راهکارشان قبول کردن طرف مقابل است و در غیر این صورت واکنششان، سرزنش کردن آن طرف است. سرزنش فرد مقابل و قرار دادن خود در جایگاه قربانی چیزی را حل نمی‌کند. با این روش شما قدرت را از خود گرفته و به فرد مقابل اعطا کرده‌اید.پیشنهاد نویسنده به جای سرزنش، «توانایی در داشتن پاسخ» است. اینکه طرحی برای پاسخی سازنده داشته باشیم. نویسنده از لغت responsability استفاده می‌کند اما تصریح می‌کند که منظورش از این لغت، response-ability است. او از ما می‌خواهد که مالکیت زندگی خود را بپذیریم. آن را به تصمیم‌های دیگران واگذار نکنیم. اهمیتی ندارد که طبیعت و اطرافیان با من چه می‌کنند. این مهم است که من چه واکنشی نشان می‌دهم. بازی من بلکه زندگی من همین است. باید از حالت انفعال، درآمده و بر روی نقشی که خود می‌توانیم ایفا کنیم تمرکز کنیم.گاهی شاید جایگزین‌های بیرونی جذابی در دسترس نباشند، اما کسی نمی‌تواند جایگزین‌های درونی را از شما بگیرد: این که هر اتفاقی که بیافتد شما ایمان خود را از دست نمی‌دهید و دست از تلاش بر نمی‌دارید. این که به عمیق‌ترین نیازها و اهداف زندگی خود وفادار باقی می‌مانید.در یکی از روایت‌های واقعی این فصل، با فردی مواجهیم که در یک حادثه بر روی یک مین به جا مانده از یک جنگ شش روزه می‌رود و پایش را از دست می‌دهد. او ماه‌های بدی را در بیمارستان با حس افسوس و ناامیدی سپری می‌کرده است. روزی سربازی که در تخت کناری او خوابیده جمله تاثیرگذاری می‌گوید: «این می‌تواند بدترین اتفاقی باشد که برای تو افتاده یا بهترین اتفاق. انتخابش با خود توست!» فرد به ظاهر قربانی تحت تاثیر این جمله رویکرد جدیدی را در پیش می‌گیرد. او یک شبکه جهانی از بازماندگان مین‌های جنگی شکل می‌دهد و به واسطه خدماتی که در زمینه بهبود اوضاع قربانیان جنگ انجام می‌‌دهد برنده جایزه نوبل و از آن مهم‌تر برنده جایزه حس رضایت درونی از بازی کردن موثر نقش خود در زندگی می‌شود. گام سوم: تصویرت را بازسازی کنحتما در این مورد شنیده‌اید که می‌توان در چالش‌ها و اختلاف‌ها به جای تصویر برنده-بازنده از ماجرا، تصویر برنده-برنده داشت. در تصویر برنده-بازنده ماجرا را همچون یک صحنه نبرد خصمانه می‌دانیم که در آن تنها یک نفر پیروز می‌شود و لاجرم دیگری شکست خواهد خورد. اما در تصویر برنده‌-برنده نوعی نگاه حل مساله برای برآورده کردن نیازها و رضایت هر دو طرف داریم. مثالی از کتاب بزنیم:In my work as a mediator, I have found that one of the most effective negotiating strategies is to look for creative ways to expand the pie before dividing it up. For example, the two departments could explore ways in which, through greater cooperation, they could increase sales and justify an increase in the budget for both.اما مشکل اینجاست که پیروی از تصویر برنده-برنده یا تصویر همکاری سازنده در میانه منازعات و درگیری‌ها کار ساده‌ای نیست. در اینجا نیز، مانند گام قبلی، نویسنده برای حل این مشکل، ما را متوجه تصویر درونی‌مان از زندگی می‌کند. او اعتقاد دارد اگر تصویری مثبت از زندگی برای خود بسازیم، آن گاه به یاری آن می‌توانیم در صحنه‌های بیرونی نیز یک نگاه سازنده و برد-برد بسازیم و آن را حفظ کنیم. او از ما می‌خواهد به فرصت‌ها و امکاناتی که در پس ناملایمات وجود دارد توجه کنیم. در واقع، شادی خودمان را بسازیم. او به این جمله آبراهام لینکلن اشاره می‌کند که:I have come to realize that people are about as happy as they make up their minds to be. شاید در شادی‌ها و کامیابی‌های بیرونی محدودیت‌هایی وجود داشته باشد اما شادی‌هایی که مبتنی بر رضایت درونی است، نامحدود است و همه می‌توانند همزمان از آن سهم ببرند. گام چهارم: تمرکزت را حفظ کنساده است که در میانه مشاجرات، گرفتار رنجش‌های مربوط به گذشته یا عصبانیت از شرایط آینده شده و از تمرکز بر روی زمان حال وابمانیم؛ اما تنها زمانی که می‌توانیم در آن نقش بازی کنیم، احساس رضایت کنیم و جریان کار را در جهت بهبود اوضاع پیش ببریم زمان حال است. تنها در صورتی که بر زمان حال تمرکز داشته باشیم می‌توانیم فرصت‌ها را کشف کنیم. این تمرکز در زمان حال در روانشناسی به حالت «flow» موسوم است و قهرمانان ورزشی گاهی از آن تعبیر «zone» می‌کنند:If tennis players, for example, get preoccupied with their last point or the next point, they will not perform well. Being fully present --being in the zone-- they can surrender to the moment and play their best. اما چطور می‌توانیم این تمرکز را حفظ کنیم؟ چطور می‌توانیم با این مقاومت درونی که ما را درگیر پشیمانی از گذشته و نگرانی از آینده می‌کند مقابله کنیم؟ پیشنهاد نویسنده در اینجا نیز به رابطه شما با خودتان برمی‌گردد. اینکه یاد بگیرید که از گذشته‌ها بگذرید. در این بخش از کتاب، جمله‌ای تامل برانگیز از برنارد شاو نقل می‌‌شود:People become attached to their burdens sometimes more than the burdens are attached to them.برخی افراد همواره حس نفرت و کینه‌ای شدید از خاطرات گذشته را با خود حمل می‌کنند اما این احساسات پیش از آن که بخواهد به دیگری آسیب بزند خود ایشان را هدف قرار داده است. از این نظر بخشش پیش از هر چیز به نفع خود ماست و این تنها مربوط به بخشودن دیگران نیست. این شامل بخشش خودمان هم هست. نفرت از خود و خاموش کردن حس عزت نفس، نقش بسیار مخربی بر ما خواهد داشت. نویسنده دامنه این گذشت را حتی از این هم فراتر می‌‌برد. او از ما می‌خواهد به غیر از این که از متهم کردن خود و دیگران دست بر می‌داریم از متهم کردن سرنوشت و زمین و زمان هم عبور کنیم و تجربیاتی که زندگی در اختیارمان قرار می‌دهد را بپذیریم.مورد دیگری که باید با آن مقابله کنیم تا بتوانیم در زمان حال تمرکز کنیم، نگرانی افراطی در مورد آینده است. به این معنا که به این نگرانی‌ها مجالی بیش از حد آنچه شایسته‌اش است بدهیم تا این نگاه، تمامی افکار و احساسات ما را احاطه کند. ضرب‌المثل چینی که در حین این بحث در کتاب نقل شده، شنیدنی است:That the birds of worry and care fly over your head, this you cannot change, but that they build nests in your hair, this you can prevent.دقت داشته باشید که در اینجا در پی نفی کامل گذشته یا آینده نیستم. فکر کردن به هر کدام از این دو در جایگاه خود می‌تواند مفید باشد اما نه به شکلی که تمرکز ما بر روی مهمترین زمانی که در آن نقش داریم -زمان اکنون- را برهم زند:We can visit the past from time to time to learn from it and we can visit the future to plan and take necessary precautions, but we make our home in the only place where we can make positive change happen: in the present moment. گام پنجم: در هر صورت احترام بگذاریدهمه با قانون مقابله‌به‌مثل آشناییم. اگر کسی ما را طرد کند ما هم او را طرد می‌کنیم. اگر مهربان و محترم برخورد کند ما هم همین کار را می‌کنیم. نکته اینجاست که با این رفتار، رابطه‌ای که تخریب شده نمی‌تواند دوباره بازسازی شود. این چرخه‌ اعمال و عکس‌العمل‌های متقابل باعث خواهد شد که هر روز تنش و دلخوری بیشتری ایجاد شود. اما گاهی فقط نیاز است که یک نفر با نگرشی متفاوت دیگران را شگفت‌زده کرده و عملی برخلاف این چرخه معیوب انجام دهد تا در مسیر بازسازی قرار گیریم. نویسنده در فصل‌های مختلف کتاب، شواهد و مثال‌هایی می‌آورد که چطور یک جو سنگین و خصمانه تحت رفتار متفاوت یک نفر، تعدیل شده و مجالی برای همکاری در حل‌و‌فصل مشکلات ایجاد شده است. این تغییر مسیر، می‌تواند صرفا با گوش دادن همدلانه، درک شرایط و نیازهای طرف مقابل و اذعان به آن رخ دهد. نویسنده پیشنهاد می‌کند که از تعلیمات «گروه ویژه» در صحنه‌های گروگان‌گیری استفاده کنیم. تعلیماتی که در یکی از پرچالش‌ترین صحنه‌هایی که می‌توانیم تصور کنیم، کارایی خود را نشان داده است: What is their first rule? Be polite. Give the hostage taker a hearing. Listen with close attention and acknowledge his or her point of view. Do not react, even if, as often happens, the hostage taker goes on the verbal attack. Stay cool and courteous, patient and persistent. In other words, respect and accept the very person who is attacking and rejecting. Meet exclusion with inclusion.احترام گذاشتن به افراد به معنای قبول داشتن رفتار ایشان حتی به معنای دوست داشتن ایشان نیست. این در مثال گروگان‌گیرها هم روشن است:Accepting those who reject us does not mean saying yes to their demands; as the hostage negotiators show, it can often mean saying no, but in a positive manner that acknowledges the other person`s inherent dignity.احترام، نوعی حق انسانی است که ما برای ایشان قائلیم و آن را پاس می‌داریم. در واقع این نگرش، نوعی احترام به خودمان نیز هست زیرا این احترام به نوع بشر و حقوق اوست. گام ششم: بده و بستانیکی از بحث‌هایی که در این فصل کتاب می‌شود این است که ما اغلب در جمع‌های خانوادگی یا با رفقایمان از قانون بده و بستان پیروی می‌کنیم. محبت و خدماتمان را دریغ نمی‌کنیم و به شکل طبیعی حس رضایت شخصی و نتیجه کارمان را در رفتارهای متقابل می‌بینیم. اما وقتی نسبت‌های فامیلی یا رفاقت قبلی نداریم کمتر خیری می‌رسانیم. می‌خواهیم تا جایی که می‌شود دریافت‌کننده باشیم یا اگر چیزی می‌دهیم پیش از آن اطمینان یابیم که همان مقدار یا بیشتر را دریافت خواهیم کرد. نکته اینجاست که قانون بده و بستان فقط در جمع نزدیکان یا رفقای صمیمی کار نمی‌کند، اگر آن را در روابط با همکاران، مشتری‌ها، کارفرماها و حتی آن دسته از افرادی که با آن‌ها به چالش و اختلاف خورده‌اید به کار ببندید، همان نتیجه را خواهید دید. اما وقتی حسابگری و پرهیز و احتیاط، رفتار غالب دو طرف می‌شود عملا فرصت‌های همکاری و بهره‌مندی از همدیگر می‌سوزد. نویسنده از کتاب معروف «بده و بستان» اثر آدام گرانت شاهد می‌آورد. طبق تحقیقات، افرادی که شخصیت بخشنده دارند، یعنی افرادی که بدون حسابگری‌های افراطی و به شکل پیش‌فرض، دانسته‌ها، تجربیات، محبت و خدمات خود را عرضه می‌کنند در طی زمان نسبت به افرادی که شخصیت گیرنده دارند، پیشرفت بیشتری می‌کنند. این افراد غیر از آن که حس رضایت بهتری از زندگی دارند و بیشتر مورد احترام هستند در نهایت معمولا ثروتمند‌تر و دارای درجه شغلی بالاتر نسبت به هم دوره‌ای‌های خود خواهند شد:One study, for example, carried out by Grant concludes that salespeople who focus on giving genuine service to customers earn more than those who are in it primarily for the money. Another study showed that people who give away more money to charity tend to be happier and end up, on average, earning more. The research suggests that giving works in part because it increases the probability that someone else will do something good for you. Giving, it turns out, is the path to personal satisfaction, both inner and outer. پس این بار نیز دیدیم که افراد ناخواسته به ضرر خود عمل کردند. خواستند با استدلالی از بخشش طفره روند اما در نهایت ضرر کردند چون قوانین بازی و روابط اجتماعی را خوب به کار نمی‌گیرند یا این طور بگوییم چون خودشان را به عنوان یکی از همین انسان‌های خوب نشناخته‌اند و مورد کندوکاو قرار نداده‌اند.اما سوال این است که چطور می‌توان این رفتار بخشش‌گری را در خود ملکه کرد؟ گام‌ها و سرمشق‌های قبلی به شما در این ارتباط کمک می‌کند. چنانچه شما حس رضایت و شایستگی را از درون خود بگیرید، این رفتار، نتیجه طبیعی آن خواهد بود. در واقع شما نه فقط به خاطر بهره‌‌مندی‌های متقابل، بلکه به خاطر لذت و حس معنایی که به زندگی‌تان می‌دهد این کار را می‌کنید.در اینجا البته ذکر این نکته ضروری است که ما نباید در این خاصیت بخشندگی زیاده‌روی کنیم. این خوب است که همیشه بخواهیم بیش از طرف مقابل و پیش از او برای همکاری اقدام کنیم اما این درست نیست که از نیازها و خواسته‌های منطقی خود بگذریم یا از پیگیری افکار و ایده‌های خود دست شسته و خمیری در دست دیگران باشیم:While an adversarial approach may prove costly and ineffective, a soft accommodating approach typically does not work much better. If we give everything away to please the customers, we may not be in business long enough to serve the customer.به بیانی دیگر باید مراقب افرادی که می‌خواهند صرفا به رفتار دریافت‌کننده خود ادامه دهند باشیم:It is, of course, important to be intelligent in one`s giving and mindful of those who merely take, otherwise you may end up doing yourself a disservice.نظر شخصی‌ام در جمع‌بندی کتابکتاب متنی روان با مثال‌هایی اثرگذار دارد که به دل می‌نشیند اما به خاطر دارم در جلساتی که در ارتباط با این کتاب داشتیم نقدهایی هم می‌شد. یکی از مهم‌ترین آن‌ها این است که در این کتاب صحبتی از «مقاومت» و «عدالت‌خواهی» نیست. این درست است که در بسیاری از تنش‌ها، چنانچه یک طرف به صحبت‌های طرف مقابل همدلانه و بدون پیش‌قضاوت گوش دهد، با درک شرایط و نیازهای طرف مقابل و اذعان به آن می‌تواند چرخه تشدید شونده دشمنی‌ها را قطع کرده و مسیری برای تفاهم و یک نتیجه برد-برد باز کند. اما آیا همیشه این طور است؟ آیا همواره سوء تفاهم‌ها و عدم آگاهی‌ها ریشه مشکلات است؟ آیا همیشه چون یک نفر با گوش شنوا شدن پیش‌قدم نشده بحران ادامه یافته است؟ در کنار مثال‌های کتاب می‌توان مثال‌های دیگری هم گذاشت که تنها مقاومت و مبارزه بوده که باعث شده حقی پایمال‌شده، به صاحبانش برگردد. فکر می‌کنم هرچند تعلیمات این کتاب در بسیاری از اختلاف‌ها و نزاع‌ها کارگشاست اما نمی‌توان با افرادی که روحیه سطله‌جویی و زیاده‌خواهی پیدا کرده‌اند و ندای اخلاق در وجودشان خاموش شده همواره از در سازش و مدارا وارد شد.انتقاد دیگری که به این کتاب وارد می‌دانم این است که شما را از قضاوت خودتان منع می‌کند. گمان من این است که اشتباهی که در اینجا شده است این فرض است که هر نوع حسابرسی و قضاوت منفی از خود منجر به انفعال، عدم تحرک و کشته شده حس عزت نفس در فرد می‌شود. در حالیکه ما می‌توانیم اعمالمان را به قضاوت بنشینیم و خود را متهم کنیم اما همچنان خود را دوست هم بداریم و برای حل مشکلاتمان به خود کمک کنیم. با وجود این نقدها، با این کتاب ارتباط برقرار کرده و آن را دوست داشتم. به عنوان یک فرد شرقی و همین طور یک مسلمان بسیاری از مطالبی که در کتاب می‌خواندم برایم آشنا بود. فرهنگ مشرق زمین با مفاهیم مراقبه، مدارا، گذشت، تامل و سکوت، قرابت دیرینه دارد. آیین‌ها و حتی ورزش‌های شرقی جدا از این مفاهیم نیستند. تم اصلی کتاب شناخت و غور در خود است. از طرفی خودشناسی، یکی از مهمترین مفاهیم دینی ماست. در حدیثی از پیامبر اکرم (ص) هست که «هر کس خودش را بشناسد خدایش را شناخته است». فکر می‌کنم کلید درک این حدیث عبارتی از قرآن باشد که خداوند درباره انسان می‌فرماید: «از روح خودم در او دمیدم». از این جا مشخص می‌شود که چرا شناخت خود به شناخت خداوند می‌انجامد. وقتی خود را عمیقا مطالعه می‌کنیم گرایشاتی متعالی در خود می‌یابیم. چیزی که در این کتاب از آن به عنوان اهداف و انگیزش‌های درونی یاد می‌شود. مثلا اگر زیاد شدن حقوق و یا جایگاه و رتبه شغلی، اهداف و انگیزه‌های بیرونی باشد علاقه به کمک کردن به هم‌نوع و رفع دردهای بشر یا شاد کردن و باسواد کردن ایشان نوعی انگیزش درونی است. پس اینجاست که زمین بازی فراخ می‌شود نه اینکه صرفا تکنیک‌های بازی عوض شود. به همین جهت است که من هم با نویسنده کتاب هم‌عقیده می‌شوم که این کتاب از کتاب‌های قبلی‌اش کامل‌تر و مهم‌تر است. تِک‌بلاگ سحاب محمد علی بزرگ‌زاده Mon, 20 Dec 2021 21:54:55 +0330 https://virgool.io/SahabPardaz/%D8%A7%D8%B3%D8%AA%D9%82%D8%B1%D8%A7%D8%B1-%D8%AA%D8%AD%D9%84%DB%8C%D9%84-%D9%BE%DB%8C%D8%B4-%D8%A8%DB%8C%D9%86%DB%8C-%D8%B1%DB%8C%D8%B2%D8%B4-%D9%85%D8%B4%D8%AA%D8%B1%DB%8C%D8%A7%D9%86-%D8%AF%D8%B1-%D9%85%D8%AD%D8%B5%D9%88%D9%84-tp01rmm5skat استقرارِ یک تحلیلِ مبتنی بر هوش‌مصنوعی مانند جانمایی درست در یک سمفونی‌ست.قبلا در این مطلب به توضیح درباره تحلیل پیش‌بینی ریزش مشتریان و نکات فنی مربوط به این تحلیل پرداخته بودیم. در این قسمت می‌خوایم سراغ استقرار تحلیل پیش‌بینی ریزش در محصول بریم. تجربه‌ای که در سحاب و روی محصول سکان به‌دست آوردیم و دوست داشتیم اون رو به اشتراک بذاریم. همون طور که می‌دونید بین استفاده از یادگیری ماشین و یادگیری عمیق در آزمایشگاه و در صنعت اختلاف معناداری وجود داره. وقتی در محیط Colab اقدام به توسعه مدل می‌کنید، صرفا بر روی دادگان مشخصی آزمایش انجام می‌دهید که اتفاقا سعی بر اینه که مدل ایجاد شده تعمیم‌پذیری خوبی داشته باشه اما این به این معنا نیست که وقتی در پروداکشن قرار می‌گیره می‌تونه به خوبی عمل کنه. وقتی یک مدل مبتنی بر یادگیری ماشین وارد یک محصول میشه باید بتونه به خوبی نیازهای فنی و بیزینسی رو پوشش بده. در واقع تحلیل ما به عنوان مثال بخشی از یک سمفونیه که باید درست نواخته بشه. مثلا اگه محصول ما با سری‌های زمانی سروکار داشته باشه، مدل آموزش داده شده بعد از مدتی منقضی می‌شه و اگه مانیتورینگ خوبی برای عملکردش داشته باشید متوجه می‌شید که کیفیت عملکردش افت پیدا کرده. تا همین جا دو نیازمندی مهم برای استقرار مدل‌‌ پیش‌بینی ریزش مشتریان در محصول مشخص شد. اول اینکه باید بتونیم به صورت دوره‌ای با داده‌های تازه و تمیز اون‌ها رو re-train کنیم و همچنین بتونیم عملکردشون رو هم مانیتور کنیم. همچنین همون طور که در این مطلب توضیح دادیم، انجام تحلیل پیش‌بینی ریزش مشتریان، نیازمند استخراج ویژگی‌های متعدد از دیتای تراکنش‌های بیزینس هست که فرایندی زمان‌بره. در فاز اکسپریمنت (experiment) می‌تونیم براش صبر کنیم اما در فاز پروداکشن و به‌خصوص زمان inference نیاز داریم که خیلی سریع انجام بشه. این قسمت بیشتر یک فرآیند مهندسی داده‌ست و از سرویس ETL سکان به عنوان ورودی، این فیچرها رو طلب می‌کنیم و اینکه چه‌طوری در لحظه، فیچر‌های مورد نیازمون آماده می‌شن رو به یک پست دیگه واگذار می‌کنیم.نکته‌ی مهم دیگه اینه که وقتی بر روی یک محصول و داخل یک تیم کار می‌کنیم نیاز داریم تا از نتایج کار‌های همدیگه آگاه باشیم و هر موقع که لازم شد بتونیم به اکسپریمنت‌های گذشته رجوع کنیم. طبیعتا این حالت هم با حالتی که تنهایی نشستیم و داریم توی Colab خوش‌گذرونی می‌کنیم فرق می‌کنه. در این حالت لازمه که بدونیم هر اکسپریمنت دقیقا با چه دیتایی اجرا شده و چه مدلی رو خروجی داده. به عبارت دیگه نیاز داریم تا experiment tracking انجام بدیم. طرف دیگه ماجرا هم یک‌سری نیازمندی‌های بیزینسی هست. همون طور که قبلا توضیح دادیم، پیش‌بینی ریزش مشتریان در واقع نوعی تلاش برای شناسایی آن دسته از مشتریانی ست که قبلا خیلی‌خوب از ما خرید می‌کردند ولی به مرور زمان خرید‌های کمتری انجام میدن. هر چقدر زودتر بتونیم تشخیص بدیم که یک مشتری می‌خواد از پیش ما بره بهتره. اینجاست که به یک مدل پیش‌بینی‌کننده با دقت و حساسیت بالا نیاز داریم. در واقع مدل آموزش داده شده قراره کار forecast انجام بده. خروجی این مدل به صورت یک عدد احتمالاتی بین ۰ و ۱ است. به این معنی که هر چقدر عدد خروجی به عدد یک نزدیک باشه یعنی احتمال رویگردانی اون مشتری بیشتر میشه و هر چقدر به صفر نزدیک‌تر باشه احتمالا اون مشتری باز هم از بیزینس ما خرید خواهد کرد. تا اینجا همه‌چیز به نظر شیک و مجلسی میاد اما بر اساس اکشنی که بیزینس مورد نظر می‌خواد با مشتریان در معرض ریزش انجام بده خروجی می‌تونه متفاوت بشه. اون چیزی که برای بیزینس مهمه یک عدد احتمالاتی نیست بلکه مدل ما باید بگه چه کسانی ریزش می‌کنند و چه کسانی فعال خواهند ماند. پس در واقع باید خروجی صفر و یک به محصول برگردونیم و از همین جا پای یک threshold به میون میاد. نقش این threshold در اینه که مشتریانی با احتمال بیش از threshold رو به عنوان ریزش‌کرده در نظر بگیریم. اما هر چقدر این threshold رو سخت‌گیرانه‌تر در نظر بگیریم میزان precision رشد می‌کنه اما میزان recall با کاهش مواجه می‌شه. از همین‌جا باید بتونید در محصول یک تعادلی بین این دو معیار برقرار کنید. همچنین چون طبق توضیحات قبلی، پیش‌بینی ریزش مشتریان اساسا یک مسئله با دادگان imbalanced هست پس لایه آخر مدل آموزش داده شده (که عموما از جنس sigmoid) است به سمت عدد صفر بایاس می‌شه. به این صورت که اگه نمودار ROC و یا PR اون رو بکشید به ازای thresholdهای بسیار نزدیک به صفر، تعادل مناسبی بین precision و recall برقرار می‌شه. برقراری تعادل بین precision و recall و همچنین حد آستانه در‌نظر‌گرفته‌شده یکی دیگه از نکات مهمیه که باید در استقرار مدل در محصول مدنظر قرار داده بشه.نمودار precision برحسب recall. طبق این نمودار هر چقدر مقدار precision افزایش یابد مقدار recall کم می‌شود.و اما نکته اصلی! بله؛ اصلا لازم داریم تا مدل آموزش داده شده به دیگر بخش‌های سیستم سرویس‌دهی کنه و عملیات inference رو پشتیبانی کنه. پس یکی دیگه از نکات مهم استقرار تحلیل پیش‌بینی ریزش در محصول، نحوه سرویس‌دهی مدل به دیگر ماژول‌های سرویس سکان است. در ادامه به سیر تکاملی راه‌حل‌هایی که در سکان به اون‌ها رسیدیم می‌پردازیم و سعی ‌می‌کنیم مزایا و معایب هر کدوم از این practiceها رو بیان کنیم.راه‌حل اول؛ خیلی ساده، خیلی عالی! Python SDKدر این راه‌حل کل لاجیک مدل‌سازی و inference رو در یک پکیج پایتون پیاده‌سازی کردیم. سپس باید این پکیج در کدبیس back-end ایمپورت بشه تا این تیم بتونه ازش استفاده کنه. از خوبی‌های این راه‌حل اینه که تا حدی به separation of concerns نزدیک شده اما از نکات منفی‌ش اینه که هنوز وابستگی‌های نامناسبی وجود داره. مثلا از تنسورفلو در SDK ما استفاده شده و وقتی ‌back-end هم می‌خواد ازش استفاده کنه باید تنسورفلو رو نصب کنه که نگهداری و نصبش در ‌back-end هم خودش داستان‌هایی داره. از طرفی هنوز یکی از خواسته‌های ما یعنی re-train های منظم در بازه‌های زمانی مختلف رو پشتیبانی نمی‌کنه و این کار رو باید تیم back-end خودش انجام بده که این یعنی یک لاجیک از تیم دیتا به تیم back-end منتقل شده و این هم نکته خوبی نیست. همچنین مانیتورینگ عملکرد مدل‌ها نیز باز به عهده تیم back-end هست که با توجه به اینکه این مدل‌ها مبتنی بر یادگیری ماشین هستند مانتورینگ‌شون هم میتونه پیچیدگی‌های خاص خودش رو داشته باشه. از همه مهم‌تر این پکیج پایتونی مثل همه کدبیس‌های دیگه نیازمند استقرار فرآیند‌های دقیق و تمیز مهندسی نرم‌افزار است. مشکل اینجاست که لاجیک این تحلیل در تیم دیتاساینس وجود داره در حالیکه پیاده‌سازی اون رو احتمالا باید افراد دیگه‌ای انجام بدن. علتش هم اینه که عموما دیتاساینتیست‌ها اصول پیاده‌سازی تمیز کد رو به‌خوبی توسعه‌دهنده‌های دیگه انجام نمیدن. همین گلوگاه مهم می‌تونه مشکل‌آفرین باشه چون نیازمند تعامل بسیار نزدیک تیم دیتا و تیم بک‌اند هست.اما نیازمندی بیزینسی که در بالا مطرح کردیم یعنی همون استفاده از حد آستانه مشخص، در این SDK پیاده‌سازی شده و به back-end این اجازه رو می‌ده که هم برچسب ۰ و ۱ و هم احتمالات رو از این پکیج دریافت کنه. نکته مهم اینه که سرویس سکان باید پیش‌بینی ریزش مشتریان رو برای بیزینس‌های متفاوتی پشتیبانی کنه و به عبارتی قراره این تحلیل و تحلیل‌های دیگه رو به مثابه یک سرویس برای بیزینس‌ها فراهم کنه. قطعا توزیع دیتای هر بیزنس از دیگری متفاوته. از همین جا سختی کار با یک ترشولد ثابت مشخص می‌شه. در حالتی که این تحلیل فقط برای یک دیتاست و برای یک بیزینس طراحی شده باشه، چنانچه ترشولد تصمیم‌گیری نهایی بر روی مقادیر نزدیک به صفر بایاس شده باشه مشکلی پیش نمیاد. چرا که با رسم نمودار ROC و یا PR می‌تونیم ترشولد مناسب رو جهت برقراری تعادل پیدا کنیم. اما اینجا لازم داریم که همواره بهترین تعادل بین precision و recall بر روی مقدار ۰.۵ در تابع sigmoid قرار بگیره چرا که سختی تحلیل رو کاربر بر اساس نیاز بیزینس باید بتونه تنظیم کنه و لازم هست که در همه بیزینس‌ها این اسلایدر تعریف و مفهوم یکسانی داشته باشه. چیزی که در وهله اول به نظر می‌رسه اینه که با down-sampling بشه بایاس شدن لایه sigmoid رو حل کرد. بنابراین لاجیک down-sampling رو هم در این پکیج پیاده‌سازی کردیم تا از بایاس شدن تابع sigmoid به دلیل وجود داده‌های imbalanced جلوگیری بشه.تصویر اسلایدر جهت تنظیم سخت‌گیری تحلیل پیش‌بینی ریزش در محصول سکانهمچنین عملا اکسپریمنت‌هایی که تیم دیتا انجام داده هم خیلی به ورژن کد مپ نشده و عملا این دو تا فاز از هم کاملا جدا هستند. به عبارتی کار اکسپریمنت در یک ریپو و کار استقرار تحلیل در محصول هم در یک ریپوی دیگه انجام می‌شه. این جدایی می‌تونه کار ما رو برای بهبود‌های آینده تحلیل‌ها سخت کنه. همچنان اکسپریمنت‌ها در کولب انجام میشه و کسی از حال دیگری خبری نداره! که این هم نشونه خوبی نیست.راه‌حل دوم؛ Kubeflow و دیگر هیچ!خب همون طور که دیدید راه‌حل قبلی نقایص بسیاری داره که باید سعی کنیم اون‌ها رو برطرف کنیم. یک راه‌حل مناسب که نسبتا به‌روز و جدید هست استفاده از kubeflow هست که مبتنیه بر kubernetes. استفاده از کیوب‌فلو مزیت‌های زیر رو داره:با استفاده از kubeflow می‌تونیم تحلیل پیش‌بینی ریزش رو به صورت یک پایپ‌لاین خوش‌تعریف دربیاریم. می‌شه اکسپریمنت‌های مختلفی رو برای این پایپلاین تعریف کنیم که در نتیجه کل تیم می‌تونه به همه این اکسپریمنت‌ها دسترسی داشته باشه. می‌تونیم برای هر پایپ‌لاین زمان‌بندی training تعریف کنیم که به صورت دوره‌ای کار آموزش بر روی دادگان جدید انجام بشه. هر دادگانی که برای اکسپریمنت استفاده می‌شه بر روی یک minio server که در کنار kubeflow بالا اومده ذخیره می‌شه. این دیتاست‌ها تحت عنوان آرتیفکت اولین کامپوننت پایپ‌لاین ذخیره می‌شن که کارش آماده‌سازی دادگان برای تحلیله. میشه برای کامپوننت‌های مختلف، آرتیفکت‌های متفاوتی تعریف کرد و اون‌ها رو ذخیره کرد.برای استفاده از kubeflow لازمه که پایپ‌لاین‌هامون رو بتونیم به فرمتی که این ابزار میفهمه بنویسیم. چیزی که این ابزار میفهمه یک فایل yml پیچیده است که تقریبا هیچ بنی‌بشری به این راحتیا نمیتونه ازش سر دربیاره اما خوش‌بختانه کیوب‌فلو یک DSL به زبون پایتون داره که با استفاده از اون می‌تونید پایپ‌لاین‌تون رو توصیف کنید. اما کار به همین‌جا ختم نمیشه. از اونجایی که برای مدل‌سازی از ابزار tensorflow استفاده کردیم به راحتی می‌تونیم از مابقی استک tensorflow هم لذت ببریم. در همین راستا میشه از ابزار TFX استفاده کرد. در واقع به جای اینکه سراغ استفاده از DSL کیوب‌فلو بریم می‌تونیم از TFX استفاده کنیم. خب شاید بپرسید که چه مزیتی داره؟ اولین نکته‌ش اینه که در واقع TFX یک لایه بر روی کیوب‌فلو هست. یعنی شما اگه پایپ‌لاین‌تون رو با TFX توصیف کنید می‌تونید هم بر روی kubeflow اجراش کنید و هم بر روی orchestrator های دیگه مانند apache airflow. نحوه توصیف چند کامپوننت از پایپ‌لاین تحلیل پیش‌بینی ریزش مشتریان رو در بالا می‌تونید ببینید. پس در واقع یک لایه با یک زبان مشترک به نام TFX ایجاد شده که پایپ‌لاین‌هایی که با اون توصیف کردید رو می‌تونید بر روی زیرساخت‌های مختلف اجرا کنید. از طرفی چون تمرکز TFX بر روی ایجاد پایپ‌لاین برای train مدل‌ها و استقرار در محصول بوده تعداد مناسبی از کامپوننت‌های ازپیش‌تعریف‌شده داره که مثل هلو می‌تونید ازش استفاده کنید. کل پایپ‌لاین تحلیل پیش‌بینی ریزش مشتریان در تصویر زیر قابل مشاهده است.نمایی از کل پایپ‌لاین تحلیل پیش‌بینی ریزش مشتریاندر این تحلیل ابتدا باید دیتاست موردنظر به پایپ‌لاین وارد بشه که این کار رو کامپوننت importexmaplegen انجام می‌ده. سپس یک سری آماره بر روی دیتای ورودی حساب می‌شه تا با استفاده از اون آماره‌ها بشه داده‌های پرت رو شناسایی کرد. همچنین داده‌هایی که با schemaی موردنظر تطابق ندارند نیز باید کنار گذاشته بشن که این کارها به ترتیب به عهده statisticsgen و schemagen هست. بعد از اون نوبت برخی از pre-processها می‌رسه که با استفاده از کامپوننت transform انجام می‌شه. (برای اینکه جزئیات پیاده‌سازی این تحلیل و لاجیک‌های هر یک از این کامپوننت‌ها رو متوجه بشید می‌تونید به این پست مراجعه کنید). حالا دیگه دیتا آماده شده و می‌تونیم با استفاده از کامپوننت trainer اقدام به آموزش مدل کنیم. در واقع بیشترین لاجیک مربوط به تحلیل، در کامپوننت‌های transform و trainer پیاده‌سازی میشه. به دلیل اینکه از TFX استفاده می‌کنیم، خیلی راحت می‌تونید برای توصیف معماری مدل از Keras استفاده کنید. بعد از آموزش هم، مدل آموزش داده شده با بهترین مدل موجود که تا الان توی scope تیم شما طراحی شده مقایسه می‌شه و چنانچه مدل جدید آموزش داده شده با معیارهای مورد نیازی که تعریف کردیم تطابق داشته باشه، کامپوننت evaluator اون رو برای کامپوننت بعدی میفرسته و همچنین اون رو به عنوان بهترین مدل جایگزین مدل قبلی می‌کنه. در این مرحله اگه به موفقیتی نرسیده باشیم پایپ‌لاین همین جا به اتمام میرسه و دیگه جلوتر نمی‌ره. چنانچه مدل بهتری رو تونسته باشیم تولید کنیم، کار دست کامپوننت pusher می‌افته و کارش اینه که مدل رو ذخیره‌سازی کنه و مدل رو به فرمت SavedModel در tensorflow ذخیره می‌کنه.اما همچنان یک چالش اصلی باقی مونده. اینکه مدل‌هایی که به عنوان خروجی پایپ‌لاین این تحلیل تولید میشن باید serve بشن. اینطوری می‌تونیم با معماری میکروسرویس به دیگر تیم‌های فنی سرویس‌دهی بکنیم که خب معماری جا افتاده و درست‌و‌درمونی هست. برای serve کردن مدل هم از tensorflow serving استفاده می‌کنیم. این ابزار می‌تونه خروجی پایپ‌لاین رو سرو کنه به این صورت که برای هر مدل یک endpoint API ایجاد می‌کنه. در واقع خروجی پایپ‌لاینی که در بالا توضیح دادیم به عنوان ورودی برای tensorflow serving استفاده می‌شه. ابزار tensorflow serving به طور دائم به محل ذخیره‌سازی کامپوننت pusher نگاه می‌کنه و چنانچه مدل جدیدی توسط کامپوننت pusher ایجاد شده باشه مدل قبلی رو به نرمی پایین میاره و مدل جدید رو serve می‌کنه (تاکید روی به نرمی داریم به خاطر اینکه فقط تقریبا اندک لحظه‌ای حس پایین بودن سرویس ایجاد می‌شه و همه‌چیز خیلی smooth هندل شده است). البته این وسط برای tensorflow serving می‌تونید version policy های زیادی رو ست کنید.جمع‌بندیبدین ترتیب تونستیم یک تحلیل پیش‌بینی‌محور رو که صرفا باهاش اکسپریمنت کرده بودیم، در پروداکشن ایجاد کنیم. با استفاده از مکانیزم‌های بالا عملیات re-training با استفاده از زمان‌بند کیوب‌فلو انجام می‌شه و همچنین عملیات inference هم با استفاده از endpoint APIهایی که tensorflow serving برامون فراهم کرده صورت می‌پذیره. با استفاده از kubeflow می‌تونیم اکسپریمنت‌هامون رو track کنیم و آرتیفکت‌های هر بار اجرای پایپ‌لاین رو هم بر روی minio-server به صورت ذخیره‌شده داشته باشیم. پروژه‌ای که در بالا توضیح دادیم تنها یکی از فعالیت‌های تیم دیتا در شرکت سحاب بود. امیدواریم که از تجربه‌ای که ما داشتیم بهترین استفاده رو ببرید! تِک‌بلاگ سحاب محمدمهدی آقاجانی Wed, 15 Dec 2021 08:49:30 +0330 https://virgool.io/SahabPardaz/%D8%A7%DB%8C%D8%AC%D8%A7%D8%AF-%D8%A2%D8%B4%D9%88%D8%A8-%DB%8C%D8%A7-%D8%A8%D9%87-%D8%A7%D9%86%D8%AA%D8%B8%D8%A7%D8%B1-%D8%A2%D8%B4%D9%88%D8%A8-xiikkj3ljwul این میمون فقط یک میمون نیست!در ابتدا باید بگویم که هدف این مقاله، تشویق به استفاده از مهندسی آشوب (Chaos Engineering) و یا نقد آن نیست و تنها به تعریف مفاهیم آن و همچنین به تجربیاتی که در سحاب به‌دست آورده‌ایم، پرداخته شده است.یک تعریف روان و دم دستی!با جستجو در اینترنت، تعریف‌های متنوع و زیادی از مهندسی آشوب می‌توان پیدا کرد؛ اما خوب است قبل از آنکه از تجربیاتمان بنویسیم، مهندسی آشوب را به زبان ساده تعریف کنیم.مهندسی آشوب، به آزمایش‌های کنترل‌شده در سیستم‌های توزیع‌شده گفته می‌شود که سبب پیش‌بینی رفتار سرویس در شرایط غیر نرمال می‌گردد.با توجه به ماهیت سیستم‌های توزیع‌شده، مسائل متعددی باعث افت کیفیت یا قطع شدن سرویس می‌شود؛ از جمله قطعی برق، تأخیر یا قطع شدن شبکه و...ایجاد آشوب هرگز با هدف پیدا کردن خطا (Bug) انجام نمی‌شود. در واقع هدف مهندسی آشوب، کنترل کیفیت نیست، بلکه صرفا با هدف آمادگی برای مواجه شدن با سوانح انجام می‌شود.به قول خانم Tammy Buttow که یکی از فعالان در حوزهٔ مهندسی آشوب است: بهتر نیست به‌جای اینکه هر روز نگران این باشیم که برق برود،‌ یک بار خودمان برق را قطع کنیم و ببینیم چه اتفاقی می‌افتد؟برای انجام آزمایش‌های کنترل شده در این حوزه، مقدمات زیادی وجود دارد؛ به عنوان مثال مجهز بودن به سامانهٔ مانیتورینگ قابل اتکا، داشتن دانش مدیریت سوانح، تعاملات قوی بین تیمی، داشتن فرایندهای تست خودکار و همچنین قابلیت استقرار خودکار کد و...مهندسی آشوب برای چه تعداد سرور مناسب است؟طبیعیست انجام این آزمایش‌ها بر روی سرویس‌هایی که شامل ۳ یا ۴ سرور است بسیار پرهزینه و بی‌فایده خواهد بود. پیچیدگی چنین پروژه‌هایی آن‌قدر نیست که هزینه/فایدهٔ انجام این کار برایتان به‌صرفه باشد.اشتباه رایج!خیلی از افرادی که با کلمهٔ Chaos در حوزهٔ مهندسی نرم‌افزار آشنایی دارند، با من هم‌نظر هستند که از کلمهٔ Chaos Monkey به عنوان یک حوزه در مهندسی نرم‌افزار یاد می‌شود؛ در صورتیکه Chaos Monkey تنها یک ابزار است، نه بیشتر.داستان برمی‌گردد به سال ۲۰۱۰ میلادی که شرکت Netflix تصمیم می‌گیرد زیرساخت فیزیکی خود را به سرورهای ابری آمازون منتقل کند. برای این کار مهندسان شرکت Netflix ابزار Chaos Monkey را توسعه داده تا مطمئن شوند که در صورت قطع شدن سرورهای آمازون، سرویس Netflix قطع نخواهد شد. حالا که صحبت از سال ۲۰۱۰ و شروع ماجرای مهندسی آشوب شد، کمی باهم تاریخ‌بازی کنیم:· سال ۲۰۱۱: مفهوم Simian Army با هدف اضافه کردن عملکردهای بیشتر به ابزار Chaos Monkey و پوشش بیشتری از شیوه‌های تزریق خطا (Failure Injection)، توسعه یافت.· سال ۲۰۱۲: نت‌فلیکس با رویکرد Fail often ابزار Chaos Monkey را در گیت‌هاب قرار داد.· سال ۲۰۱۴: برای اولین بار، سِمَت Chaos Engineer (مهندس آشوب) در شرکت نت‌فلیکس تعریف شد. تعریف این سمت شغلی باعث شد که ابزاری به نام (Failure Injection Testing (FIT به‌وجود بیاید. هدف از این کار داشتن کنترل بیشتر و کمتر کردن حالات تصادفی در اجرای تست‌ها بود.· سال ۲۰۱۶: شرکت‌های دیگری مانند Gremlin تاسیس شد که مدیران اصلی این شرکت‌ها اغلب از شرکت نت‌فلیکس بودند.· سال ۲۰۱۸: شرکت گرملین کنفرانس بزرگی را با نام Chaos Conf را طراحی کرد.· سال ۲۰۲۰: شرکت آمازون، مهندسی آشوب را به صورت رسمی به (WAF (Well-Architected Framework خود اضافه کرد.با یک نگاه کلی به این تاریخچه، می‌توان به اهمیت این حوزه در بحث مهندسی نرم‌افزار در سال‌های اخیر پی برد؛ اما وقتی نام شرکت‌هایی را که در حال حاضر، در حال بهره‌برداری از این حوزهٔ مهندسی هستند، می‌بینیم، بیش از پیش به نفوذ مهندسی آشوب در حوزهٔ مهندسی نرم‌افزار پی می‌بریم. نام شرکت‌هایی که در ادامه آمده است، می‌تواند پشتوانهٔ خوبی برای اعتبار این حوزه باشد. شرکت‌هایی همچون:نت‌فلیکس، لینکداین، فیس‌بوک، گوگل، مایکروسافت و آمازونخب که چه!؟سؤال خوبیست. ما در سحاب سرویس‌های داده‌محور ارائه می‌کنیم. پس برای مدیریت این داده‌ها نیاز به سیستم توزیع‌شده با تکنولوژی‌های بیگ‌دیتایی داریم. محیط اجرا آن‌قدر پویا و در حال تغییر است که نمی‌توانیم برای تغییرات روی محیط اجرا، به‌ صورت مکرر به مشتری،درخواست Downtime بدهیم؛ یا این که آن‌قدر برق رفتن تبدیل به امری عادی شده که تصمیم گرفتیم برای یک بار هم که شده خودمان برق را قطع کنیم ببینیم چه می‌شود. به همین دلیل کمربندمان را محکم کردیم و زدیم به دل تحقیق و توسعه دربارهٔ این حوزه.پیش از اجرا...ابزار موجود را دیدیم، پیش‌نیازها را بررسی کردیم، سامانهٔ مانیتورینگمان را قابل اتکاتر کرده و از همه مهم‌تر برای مسئلهٔ Disaster Recovery کارهای خوبی انجام دادیم و به محض این که شرایط را برای اجرای این نوع از تست‌ها آماده دیدیم، به همراه تیم‌هایDevOps، SRE، Change management، Development و...، به‌ خط شدیم که برنامهٔ عملیات (Action plan) را استخراج کنیم.پس از استخراج برنامهٔ عمليات، شعاع انفجار (Blast Radius) را هماهنگ کردیم. در تحقیقاتی که انجام شد، بِه‌‌روش‌هایی (Best Practices) که در حوزهٔ مهندسی آشوب وجود داشت، دلالت بر کمینه کردن شعاع انفجار در ابتدای انجام آزمون‌ها داشت. ما هم خومان را از این قاعده مستثنی نکردیم و تا توانستیم با صبر و حوصله، اما با اطمینان خاطر، نقشهٔ اجرا را چیدیم.داخل پرانتز بگوییم که، مهندسى آشوب در سطوح زیر قابل انجام است:· در سطح زیرساخت سخت‌افزاری· در سطح شبکه· در سطح نرم‌افزاراینکه چه مواردی را در نقشهٔ اجرا لیست کردیم در ادامه می‌بینیم:۱- لیست سرویس‌هایی که باید مورد آزمون قرار می‌گرفتند را کشف کردیم.۲- لیست ماشین‌ها را به همراه آدرس آی پی آنها پر کردیم.۳- سرویس‌ها را بر اساس مخاطرات و دامنهٔ اثرشان مرتب کردیم.۴- درخواست تغییر (RFC) را آماده کردیم و ...اجرا...ما تصمیم گرفتیم برای شروع به سراغ اجرای آزمون در سطح شبکه برویم. چگونه؟به این صورت که ابزاری که نوشتیم، به صورت خودکار شبکهٔ ماشین(ها)ی هدف را مختل می‌کند (این اختلال قابل کانفیگ است و می‌تواندشامل Packet Loss یا Delay و یا حتی قطعی کامل شبکه باشد). پس از اختلال در شبکه و در بازه‌ای که برای اختلال در کانفیگ در نظر گرفتیم، آزمون اصلی شروع می‌شود و از طریق سامانهٔ مانیتورینگ بررسی می‌کنیم که اوضاع سرویس به چه شکل است. نکتهٔ مهم این است که با این که دامنهٔ اثر را در ابتدا بسیار کوچک در نظر گرفتیم، اما تیم‌های پشتیبانی و مدیریت سانحه On-call بودند. بعد از آن که اجرای آزمون به اتمام رسید، ابزار، باز هم به‌ صورت خودکار، وضعیت شبکه را به حالت پایدار (Steady State) برمی‌گرداند.متخصصان توصیه می‌کنند چنین مانورهایی در ابتدا در محیط آزمایشگاه صورت بگیرد.پس از اجرا...راستش را بخواهید از همین تکرارها در محیط آزمایشگاه، درس‌ها و نکات زیادی کشف می‌شود. مثلا اینکه هرچقدر که تلاش کنیم، بازهم معماری محیط اجرا با معماری محیط آزمایشگاه کاملا یکی نخواهد شد؛ اما با اجرای این آزمون‌ها (Chaos Engineering) تا حد بسیار زیادی دو محیط را به هم نزدیک خواهید کرد. نکتهٔ دیگر این است که تکنولوژی‌هایی مثل hadoop و kafka و HBase کاملا وابسته به کانفیگ هستند. از کجا می‌دانید که کانفیگی که برای این تکنولوژی‌ها انجام داده‌اید، HA بودن سرویس را تضمین می‌کند؟ آیا فرضیه‌ای (Hypothesis) وجود دارد که برای آن، راه حل اثبات وجود داشته باشد؟سامانهٔ مانیتورینگ ما در طول اجرای آزمونی که بر روی تکنولوژی HBase اجرا کردیم، خطایی داد که در نگاه اول اصلا مشخص نبود به چه دلیل است؛ اما بعد از بررسی متوجه شدیم که گره HMaster خودکشی کرده است. چرا؟ در آن لحظه نمی‌دانیم! فقط می‌دانیم که با اختلالی که در شبکه ایجاد کرده بودیم، این اتفاق افتاد. اینجا بود که به ابزاری که آماده کرده بودیم بیش از پیش افتخار کردیم؛ چرا که با ۱ تیر چند نشان زده بودیم: سامانهٔ مانیتورینگ را ارزیابی کردیم، ابزار ایجاد آشوب را امتحان کردیم و نیز متوجه شدیم که سرویس HBaseمان چقدر دسترس‌پذیر است.تکلیف سرویس‌های وابسته چیست؟!ما در برنامهٔ عملیاتمان برخی از سرویس‌های وابسته را لیست نکرده بودیم؛ اما در زمان اجرای آزمون‌ها، متوجه شدیم که با از کار افتادن برخی سرویس‌ها، تعدادی از سرویس‌های دیگر هم دچار اشکال می‌شوند. (بازهم دلیلی دیگر برای اجرای آزمون‌ها در آزمایشگاه)یکی از بزرگترین دستاوردهای ما این بود که با انجام این آزمون‌ها، توانستیم با پشتوانهٔ علمی، به مشتری‌هایمان بگوییم که مؤلفه‌های محیط اجرا کاملا دسترس‌پذیر (Highly Available) هستند.درس بزرگی که از این عملیات یاد گرفتیم این بود که توانستیم به این اعتماد به‌نفس برسیم که به چالش کشیدن مؤلفه‌ها در محیط اجرا حتی در زمان بالا بودن سرویس و با تمام ملاحظات و مخاطرات دیگر، میسر است. لذا مسیر برای رفتن به سمت انجام چنین ارزیابی‌هایی بیش از پیش میسر شد.حرف آخرآشوب را ایجاد کنید و نگذارید که آشوب، شما را ایجاد کند. (شوخی!)اما اگر می‌خواهید مثل ما در سحاب، مؤلفه‌های در حال اجرا را در همان محیط اصلی (محیط Production) و بدون گرفتن Downtime از مشتری، مورد ارزیابی قرار دهید، هر چقدر که می‌توانید آزمون خودکار نوشته، انتشار و استقرار نسخه‌ها را کاملا خودکار کرده و جملهٔ Fail Fast Fail Often را در واقعیت بالفعل کنید.همچنین شاید بد نباشد که مراحل اجرای ارزیابی‌های مهندسی آشوب را به‌صورت زیر بنویسیم:پیش از اجرابرنامه‌ریزی برای Disaster Recoveryداشتن سامانهٔ مانیتورینگ قابل اتکاتهیهٔ نقشه‌ٔ اجرا (Action Plan)اجراآماده کردن آزمون‌های کاملا خودکار جهت تزریق خطا در محیط اجرا (Production)نگهداری حالت Steady State برای برگشتن به این حالت، بعد از اتمام ارزیابیکمینه کردن شعاع انفجار (Blast Radius)اجرای ارزیابی در محیط آزمایشگاهاجرای ارزیابی در محیط اجراپس از اجرابررسی نتایج به‌دست آمده در سامانهٔ مانیتورینگاگر دوست داشتید می‌توانید برای دانستن بیشتر در مورد تجربیات سحابی، مقاله‌های دوستان خوبم در اینجا را هم مطالعه کنید. همچنین اگر شما هم تجربه مشترکی در این زمینه دارید خوشحال می‌شوم که در زیر این پست، تجربیات خود را با ما به اشتراک بگذارید.متشکرم! تِک‌بلاگ سحاب مجتبی یوسفی Tue, 07 Sep 2021 09:54:46 +0430 https://virgool.io/SahabPardaz/%D8%B1%D8%A7%D9%87-%D8%A7%D9%86%D8%AF%D8%A7%D8%B2%DB%8C-%D8%B3%D8%B1%D9%88%D8%B1-ci-%DA%A9%D9%88%D8%B2%D9%87-%DA%AF%D8%B1%DB%8C-%DA%A9%D9%87-%D8%A7%D8%B2-%DA%A9%D9%88%D8%B2%D9%87-%D8%B4%DA%A9%D8%B3%D8%AA%D9%87-%D8%A2%D8%A8-%D9%85%DB%8C-%D8%AE%D9%88%D8%B1%D8%AF-yvbx2yvkyl5e در این نوشته قصد داریم از زاویه نگاه کیفیت به سراغ گوشه‌ای از گودِ توسعه‌ی محصول برویم که با اینکه داعیه‌دار ارتقای کیفیت محصولات نرم‌افزاری‌ست، اما عمدتا خودش کیفیت بالایی ندارد: سرور CI.‏Self-Hosted CI Server چیست؟گاهی به علت نیاز به منابع پردازشی بیشتر، شخصی‌سازی، صرفه‌جویی در هزینه‌ها، رعایت محرمانگی و ... نمی‌توان از زیرساخت‌های عمومیِ CI استفاده کرد. اکثر پلتفرم‌های این حوزه (نظیر Gitlab CI و Github Actions) در پاسخ به این نیازمندی‌ها امکان استفاده از Self-Hosted CI Server را فراهم کرده‌اند تا بتوان از امکانات همان پلتفرم در سرور شخصی بهره برد.برای اطلاعات بیشتر در این باره می‌توانید به توضیحات گیت‌هاب و گیت‌لب مراجعه کنید.مشکل چیست؟وقتی مجبور می‌شویم برای پروژه‌ی خود یک یا چند Self-Hosted CI Server راه‌اندازی کنیم، غالبا دست به یک کار هنری می‌زنیم؛ مجموعه‌ای از آزمون‌و‌خطاها و اعمال تنظیمات و نصب ابزارهای مختلف، برای رسیدن به یک سرور مناسب در اسرع وقت.تا اینجای کار کاملا طبیعی است. اولین قدم‌ها همواره قدم‌هایی نوآورانه و بدون چارچوب هستند. مشکل از آنجایی شروع می‌شود که وقتی به مرحله‌ای رسیدیم که سرور CI کارمان را راه انداخت، رهایش می‌کنیم.مشکل به اینجا هم ختم نمی‌شود؛ بسته به نیاز پروژه در زمان‌های مختلف، تغییراتی روی سرور CI اعمال می‌کنیم و پس از مدتی به معنای واقعی کلمه با یک کار هنری مواجهیم: چیزی که سازنده‌اش هم نمی‌تواند بازتولیدش کند!از اینجا به بعد، آپدیت زیرساخت CI، تغییر تنظیمات سرور CI، آپدیت ابزارهای نصب‌شده در آن، دیباگ مشکلات در سرور و ... نیازمند انرژی زیادی برای انجام خواهند بود. به طوری که پیشنهاد یک تغییر ساده در سرور CI احتمالا با این واکنش‌ها مواجه خواهد شد: «این را بگذاریم برای آخر هفته»، «فعلا فرصت این کار را نداریم»، «بچه‌ها امروز کامیت نکنید تا CI درست شود»، «این تغییر را باید فلانی انجام دهد» و ...اگر به هر دلیلی سرور CIتان دچار مشکل شود یا از دست برود، احتمالا تا یک هفته نمی‌توان به شرایط پایدار سابق بازگشت. زیرا شرایط سابق تعریف مشخصی برای بازتولید ندارد و کوچکترین اختلاف در تنظیمات هرجای سیستم ممکن است نتیجه‌ی جاب‌ها را دگرگون کند. در قسمت بعد نمونه‌ی این تنظیمات آمده است.این‌ها دقیقا همان مشکلاتی هستند که برای جلوگیری از آن‌ها در محصول نهایی خود، دست به دامن CI شده بودیم. انگار فراموش کرده‌ایم که اصلا در راستای چه آرمان‌هایی سراغ مفهوم Continuous Integration رفته بودیم!تحت داکر بودن کافی نیست!ممکن است در ابتدا راه‌حل را در این ببینیم که جاب‌های CI را در محیط داکر - یا سایر تکنولوژی‌های مشابه - اجرا کنیم تا کمترین وابستگی را به محیط میزبان CI داشته و مشکلات فوق را پشت سر بگذاریم.اگرچه containerization برای محیط CI بسیار توصیه شده و لازم است، اما کافی نیست. حتی در شرایطی که همه‌ی جاب‌های CI تحت داکر اجرا می‌شوند، هنگام تغییر، ارتقا یا بازسازی سرور CI، ممکن است با رفتارهای ناسازگاری در آن مواجه شوید و روزها برای پاس کردن پایپلاینی که تا دیروز مشکلی نداشت تلاش کنید!فهرست زیر شامل برخی موارد است که در سرور میزبان CI ممکن است بر اجرای جاب‌ها تاثیرگذار باشد:- نسخه‌ی داکر- نسخه‌ی کرنل سیستم‌عامل- احراز هویت در رجیستری‌های private (برای دانلود ایمیج خود جاب)- تنظیمات مربوط به registry mirror- تنظیمات مربوط به insecure registries- دسترسی شبکه به سرویس‌های جانبی- تنظیمات مربوط به امکان / عدم امکان اجرای موازی جاب‌ها- و...راه‌حلراه‌های مختلفی برای مقابله با مشکل یادشده وجود دارد. مثلا می‌توان از سرور CI (همان کار هنری!) snapshot گرفت و در مواقع لزوم از آن استفاده کرد.اما راه‌حل پیشنهادی ما این است که مراحل راه‌اندازی و تنظیم سرور CI در قالب اسکریپت، خودکار شود.این کار نه‌تنها باعث می‌شود وضعیت سرور CI قابل بازتولید باشد، بلکه امکان مرور جزئیات آن را در اختیار همه‌ی اعضای تیم قرار می‌دهد. بعلاوه تجربه نشان داده که طی این خودکارسازی، بسیاری از ابزارها و تنظیمات اضافی یا اشتباه، خود را نشان داده و حذف خواهند شد.خودکارسازی راه‌اندازی سرور CIما داخل تیم خود در سحاب اسکریپت‌هایی نوشتیم که با معرفی یک سرور تازه‌نفس، آن را تبدیل به یک سرور CI می‌کند. طی این کار، تجربه‌هایی کسب کردیم که در ادامه به اختصار با شما در میان می‌گذاریم. امیدواریم برای شما هم مفید باشند. فایل‌های مربوط به ساخت و تنظیم سرور CI در یک فولدر در مخزن خود پروژه نگهداری شود.تنها پیش‌فرضی که از ماشین مقصد باید وجود داشته باشد، نسخه‌ی سیستم عامل و تنظیمات شبکه (برای دسترس‌پذیری ماشین میزبان) است.مطابق طراحی اکثر سرویس‌های CI، سرور مربوطه به صورت stateless نگهداری شود. یعنی ذخیره‌ی هرگونه داده توسط جاب‌های CI، خارج از سرور انجام شود تا فرایند update / rollback سرویس بی‌نیاز از data migration باشد.البته وجود cache در سرور CI بلامانع است. به شرط آن که به معنای واقعی کلمه cache باشد نه data. یعنی از بین رفتن آن خللی در functionality سیستم CI ایجاد نکند.در هنگام طراحی جاب‌های CI کمترین میزان وابستگی به سرور CI موجود باشد و حتی الامکان از روش‌های virtualization (نظیر Docker) بهره گرفته شود.با توجه به اینکه برای اجرای خود اسکریپت، طبیعتا سرور CI/CD وجود ندارد، نیاز است تا نکات زیر رعایت شود:- اسکریپت با این پیش‌فرض نوشته شود که قرار است در کامپیوتر شخصی اجرا گردد.- حتی‌الامکان اسکریپت مربوطه به حداقل پیش‌نیازها برای اجرا وابسته باشد.- اجرای اسکریپت به سادگی اجرای یک فایل bash یا شبیه آن باشد، بدون هیچگونه flag و تنظیمات اضافه. (هر آپشنی با توضیحات مرتبط به صورت interactive از کاربر گرفته شود.) این کار در راستای عمل به شیوه‌ی Document as Code است. به بیان دیگر، مستندات مربوط به راه‌اندازی سرور CI باید تنها یک جمله باشد: «فلان اسکریپت را اجرا کنید!»پیش‌فرض‌هایی که اسکریپت مطابق آن‌ها نوشته شده، assert شوند و در صورت مغایرت، خطای متناظر به صورت گویا چاپ شود.- پیش‌فرض‌های سرور:. نوع سیستم عامل. نسخه‌ی سیستم عامل. دسترسی تحت شبکه به سرویس‌های دیگر. (در صورت نیاز) حداقل منابع پردازشی مورد نیاز- پیش‌فرض‌های کلاینت (همان اسکریپت interactive):. پیشنیازهای اجرای اسکریپت (مانند نسخه‌ی انسیبل، ابزار sshpass و ...)هر تغییر در تنظیمات سرور CI باید توسط تغییر و اجرای اسکریپت مربوطه اعمال شود. (حتی الامکان خودتان ssh نزنید!)از عمومی و کلی کردن ساختار اسکریپت خودداری شود. اسکریپت تنها وظیفه دارد سرور CI مربوط به پروژه‌ی کنونی خودش را تنظیم کند.اگرچه عمومی بودن اسکریپت در ظاهر جذاب به نظر می‌رسد، اما باعث می‌شود پارامترهای وروردی بسیار زیاد و گیج‌کننده شوند. مضاف بر اینکه برخی تنظیمات واقعا خاص سرور CI پروژه است و عمومی کردن آن اساسا بی‌معنی است؛ مانند گواهی SSL مربوط به سرویس‌های داخلی، که اصلا برای یک پروژه‌ی دلخواه دیگر ممکن است به کل نیاز نباشد.به طور کلی، هدف اسکریپت خودکار، راه‌اندازی سرور CI در شرایط کنونی شرکت / پروژه است و طبیعتا با تغییر این شرایط، اسکریپت نیز می‌تواند تغییر کند.پارامترهای غیرمحرمانه (مانند گواهی SSL شرکت) حتی الامکان hard-code شوند. این کار باعث می‌شود اجرای اسکریپت برای اجراکننده (که ممکن است هرکسی باشد) ساده‌تر شود.موارد آخر احتمالا با پیش‌فرض‌های بسیاری از ما هماهنگ نیست. مثلا همه‌ی ما عمدتا تلاش کرده‌ایم تا یک قابلیت را در صورت امکان به صورت عمومی‌تر فراهم کنیم (مورد ۸) یا اصرار داشته‌ایم که پارامتر‌های هاردکدشده را به بیرون کد منتقل کنیم (مورد ۹). اینجا هم، مثل هزاران موضوع دیگر در مهندسی نرم‌افزار، با یک trade-off روبرو هستیم که برآورد هزینه/فایده‌ی آن را به خودتان واگذار می‌کنیم.ایام به کام و پایپلاین‌هایتان پاس! تِک‌بلاگ سحاب عمران باتمان‌غلیچ Wed, 25 Aug 2021 18:49:52 +0430 https://virgool.io/SahabPardaz/%D8%B3%D8%A7%D8%AE%D8%AA-api-%D9%85%D8%AF%D8%B1%D9%86-%D8%A8%D8%A7-graphql-%D8%A8%D8%AE%D8%B4-%D8%B3%D9%88%D9%85-ggmcmby8syxc در بخش‌های قبل (۱ و ۲) گرف‌کیوال رو معرفی کردیم و به کمک جنگو گرافین یک ای‌پی‌آی ساده ساختیم تا با مفاهیم اولیه گرف‌کیوال و گرافین آشنا بشیم. در این بخش توضیح می‌دم چگونه کدها رو لایه بندی کنیم که پروژه‌ی تمیزتر و قابل نگه‌داری داشته باشیم.قبل از شروع این بخش لازمه مستندات graphql و مستندات graphene رو مطالعه کرده باشید و با مفاهیم‌شون آشنا باشید.این پروژه در این آدرس در دسترس عموم قرار دارد.لایه بندی و تفکیک وظایفاگه بخوایم بی‌خیال و کثیف کد بزنیم، چی کار باید بکنیم؟ یه تابع می‌نویسیم که همه کار توش انجام بشه. ریکوئست توش گرفته می‌شه، جیسون توش پارس می‌شه، هدر خونده می‌شه و تشخیص می‌ده که کاربر لاگین هست یا نه، چند تا شرط رو چک می‌کنه که ببینه کاربر دسترسی داره یا نه، یه چند تا کوئری هم به دیتا بیس می‌زنه، شاید یه چهار خط اون وسط چند تا منطق کسب و کار (Business logic) هم اعمال کنه، آبجکت جیسون رو سریالایز کنه و بنویسه در جواب ریکوئست، ناقابل چهارصد خط، تست هم که نداره، اصلا ما اهل این سوسول بازی‌ها نیستیم، تازه بخوایم تست هم بنویسیم نمی‌شه، پس به جد بی‌خیال تست.برای اینکه این اتفاق نیفته، لازمه که کدها لایه بندی مناسب داشته باشند، لایه بندی کد به ما کمک می‌کنه تا هر لایه رو بتونیم به طور مستقل مورد توجه قرار بدیم و در هر لایه تنها دغدغه‌های همون لایه رو داشته باشیم و حداکثر لازمه که interface لایه‌های دیگه رو مد نظر قرار بدیدم.یه لایه بندی خوب، برای ما تعریف می‌کنه که هر لایه چه وظایفی داره، چه فرضیاتی داره و مهم‌تر از اون چه فرضیاتی نداره، چه لایه‌ای رو می‌شناسه و چه لایه‌ای رو نباید بشناسه.لایه‌های جنگو و گرافینوقتی داریم با گرفین یک ای‌پی‌آی گرف‌کیوال پیاده می‌کنیم، اکثر کدهای ما در این دو دسته می‌گنجه: کدهای تعریف تایپ و کدهای تعریف resolver. کدهای تعریف تایپ به صورت اعلامی (declarative) هستند و اکثر کدهای دارای منطق ما در بخش resolver ها اجرا می‌شن. خوبه قبل از اینکه بریم و بخوایم لایه بندی‌های کد خودمون رو مشخص کنیم، ببینیم در اطرافمون و در جنگو و گرافین چه لایه‌هایی وجود داره و به چه لایه‌هایی دسترسی داریم.وقتی یه درخواست از کاربر به اپ جنگوی ما می‌رسه، ابتدا جنگو مواردی مثل پارس کردن ورودی رو انجام می‌ده. البته جنگو صرفا مواردی مثل json و query param و form data رو می‌شناسه و گرف‌کیوال رو نمی‌شناسه. همچنین مواردی مثل اینکه درخواست دهنده چه کاربری هستش رو از روی مواردی مثل کوکی‌ها تشخیص داده و از طریق request.user در اختیار ما قرار داده. خود این کارهای در داخل جنگو در چندین لایه مجزا انجام می‌شه، ولی فعلا همین که بدونیم به صورت کلی این کارها قبل از رسیدن درخواست کاربر به دست ما توسط جنگو انجام می‌شه، کافیه در لایه‌ی بعدی، گرفین وجود داره که موضوعات مربوط به گرف‌کیوال رو می‌شناسه. بلده کوئری گرف‌کیوال رو پارس بکنه، ورودی‌های کوئری بگیره و صحت‌سنجی و تبدیل کنه و resolver متناسب با کوئری رو صدا بزنه و در ادامه خروجی رو بگیره و صحت سنجی کنه و بدست جنگو بسپاره تا به عنوان جواب درخواست به کاربر برگردونده بشه.لایه‌ی دیگه که جنگو در اختیار ما قرار داده، لایه ORM هستش که به ما کمک می‌کنه بتونیم داده‌ها رو در پایگاه‌داده ذخیره و بازیابی کنیم.احراز هویت و مجاز شمارییکی از مسائلی که تقریبا تمام سرویس‌ها با اون مواجه هستند، دو مسئله‌ی «احراز هویت» و «مجاز شماری» است. خوبه اول این دو مورد رو تعریف کنیم:احراز هویت: احراز هویت یا Authentication قراره این سوال رو جواب بده، کاربر چه کسی هستش؟مجاز شماری: مجاز شماری یا Authorization قراره این سوال رو جواب بده که کاربر حق داره چه کارهایی انجام بده؟این دو موضوع رو کجای کد باید اعمال کنیم؟همون‌طور که قبل‌تر گفته شده، احراز هویت توسط جنگو انجام شده. ولی منطق مربوط به مجاز شماری، کاملا به کسب و کار ما بر می‌گرده و این ما هستیم که باید کدش رو بزنیم. کدهای مجاز شماری رو کجا بزنیم؟ وسط کدهای resolver گرف‌کیوال خوبه؟ نه.فرض کنیم ما بجز گرف‌کیوال ممکن است روش‌های ارتباطی دیگه‌ای مثل rest یا cli یا grpc یا تمپلیت‌های جنگو داریم. اگه ما کدهای مجاز شماری رو داخل resolver گرف‌کیوال بنویسیم، این منطق مجاز شماری تنها روی گرف‌کیوال اعمال می‌شه و مثلا روی کدهای رِست اعمال نمی‌شه. یا اگه بخوای اعمال بشه، لازمه کدهای مشابه زده بشه و معلوم هم نیست با چه مکانیسمی قراره این منطق‌ها با هم سینک بمونند و احتمالا بعد از یه مدت می‌بینیم منطق اعمال مجاز شماری بین روش‌های ارتباطی مختلف، فرق کرده و تفاوت رفتار دارند. مثلا کاربر از طریق گرف‌کیوال تنها پست‌های منتشر شده رو می‌تونه ببینه، ولی از طریق رِست همه‌ی پست‌ها رو می‌بینه در حالی که نباید این اتفاق می‌افتاد.اینکه یه کاربر حق داره چه کارهایی بکنه و چه چیزهایی رو ببینه ربطی به این نداره که این کاربر از چه طریقی به اپ ما وصل شده.روش نامناسب اعمال مجاز شماری منبعخب پس باید چی کار کنیم؟لایه منطق کسب و کارجواب اینه که باید یه لایه داشته باشیم که منطق کسب و کار ما بر عهده‌ی اون لایه باشه و بخشی از وظایف لایه کسب و کار، اعمال قواعد مجاز شماری هستش. به این ترتیب در لایه‌ی گرف‌کیوال و در کدهای resolver که ما می‌نویسیم، نباید اثری از کدهای مجازشماری و کدهای منطق کسب و کار وجود داشته باشه.در غیر این صورت مجبور می‌شیم که این کدها رو در روش‌های ارتباطی دیگه مثل رِست هم کپی کنیم.روش مناسب اعمال مجاز شماری منبعلایه کسب و کار قرار نیست ذره‌ای در مورد پروتکل‌های http و گرف‌کیوال و ... بدونه، این لایه باید منطق خالص باشه. و تنها حق داره لایه‌ی داده رو بشناسه. خود من وقتی با جنگو کد می‌زنم، اجازه می‌دم لایه کسب و کار، ORM جنگو رو به عنوان لایه‌ی دیتا بشناسه و از اون استفاده کنه، ولی به هیچ وجه مواردی مثل http توی کدهای این لایه نیست.سوالی که اینجا پیش می‌آد اینه که پس لایه گرف‌کیوال اینجا چی کار می‌کنه؟ با این روش، لایه گرف‌کیوال یه لایه‌ی بسیار نازک می‌شه که یه وظایف بیشتر نداره: صدا کردن تابع مناسب از لایه‌ی کسب و کار و پاس دادن ورودی‌های گرفته شده از کاربر به لایه‌ی کسب و کار. در صورت لزوم ممکن است برای این که ورودی‌ها مناسب لایه‌ی کسب و کار بشه، یه تبدیل روی ورودی‌ها انجام بده. ولی باید مراقب باشیم هیچ بخشی از مجاز شماری و یا منطق کسب و کار در لایه گرف‌کیوال نباشه. در حالت ایده‌آل هیچ عبارت شرطی مثل if در لایه‌ی گرف‌کیوال و resolver ها وجود ندار.در ادامه یه کم دست به کد می‌شیم.مثال عملیفرض بگیریم یه تعداد پست داریم، که برخی از این‌ها در وضعیت پیش‌نویس قرار دارند و برخی هم منتشر شده‌اند. قرار است همه‌ی کاربران بتوانند پست‌های منتشر شده را ببینند ولی پست‌های پیش‌نویس تنها توسط نویسنده قابل مشاهده می‌باشد.منطق کسب و کار داخل resolverدر نگاه اول، این کد داره کار می‌کنه و همه چی خوبه، ولی نکته اینجا است که ممکنه کد مشابهی هم در بخش‌های مربوط به رِست و یا view های جنگو زده شده باشه. ولی اگه فردا روزی لازم بشه این منطق عوض بشه،‌ اون وقت لازمه که بریم چند جا رو به صورت مشابه تغییر بدیم و حتی ممکنه بعضی موارد رو فراموش کنیم و رفتار رِست و گرف‌کیوال متفاوت بشه.برای اصلاح، همون طور که بالاتر بحث شد، یک لایه‌ی جدید باید ایجاد کنیم که منطق‌های مخصوص کسب و کار در اون بخش نوشته شده باشه. من اسم این لایه رو interactor گذاشتم. رویه‌ی من در جنگو این طور بوده که interactor ها تنها حق دارن آبجکت‌های مربوط به مدل رو بشناسن و از مواردی مثل http و graphql نباید خبر داشته باشن. یک interactor می‌تونه یک تابع و یا یک کلاس باشه. در این مورد ساده، من یک تابع تعریف می‌کنم. (اسم interactor از این ارائه‌ی uncle bob گرفته شده)تابع interactorتعریف resolver با استفاده از interactor و بدون پیاده‌سازی مستقیم منطق کسب و کاردر لایه‌ی گرف‌کیوال و کد resolver دیگه اثری از کدهای مربوط به منطق کسب و کار ما وجود نداره و در کد resolver تنها تابع interactor استفاده شده. این تابع interactor می‌تونه به صورت مشترک بین رِست و دیگر روش‌های ارتباطی به صورت مشترک استفاده بشه و در صورتی که لازم شد منطق کسب و کار ما تغییر کنه، فقط اون تابع interactor تغییر می‌کنه.چرا به جای user متغییر info ویا info.context رو به عنوان ورودی به تابع interactor پاس ندیم؟ چون info یه آبجکت مربوط به graphql هستش و info.context هم یک آبجکت مربوط به http هستش و قرار نیست لایه منطق کسب و کار ما از این موضوعات خبر داشته باشند. مثلا اگه info ورودی بود، دیگه بخش مربوط به رِست نمی‌تونست از این تابع استفاده کنه. اگه info.context رو پاس می‌دادیم، بخش مربوط به rpc دیگه نمی‌تونست از این تابع استفاده کنه. ولی user مربوط به لایه‌ی ORM هستش و بنابر این interactor حق داره درباره‌اش بدونه.تغییر شاید کوچک به نظر برسه، ولی به شدت در تمیزی کد و نگه‌داشت‌پذیری کد (maintainability) کمک کننده هستش، مخصوصا اگه چند کانال ارتباطی مثل رِست و گرف‌کیوال به صورت همزمان وجود داشته باشه و یا اینکه منطق‌های کسب و کار پیچیده باشه، این موضوع بیشتر آشکار می‌شه. در این آدرس می‌تونید نمونه‌ی interactor ها رو در یک پروژه‌ی واقعی ببینید که به نسبت پیچیده‌تر هستند و تعدادشون هم اون‌قدر زیاد هستش که به جای یک فایل، یک پوشه interactors داریم.نکته‌ی جذاب دیگه این هستش که می‌تونیم کدهای مربوط به منطق کسب و کار رو مستقل از بقیه لایه‌ها تست کنیم:تست منطق کسب و کارجمع بندیدر این بخش بررسی کردیم که با اضافه کردن یک لایه‌ی کسب و کار می‌تونیم کد را تمیزتر کنیم و نگه‌داشت‌پذیری کد را افزایش بدیم.در بخش بعدی در این مورد صحبت خواهیم کرد که چطور می‌تونیم تا جای ممکن اپ‌های جنگو رو از هم مستقل نگه داریم تا قابلیت استفاده‌ی مجدد از اون‌ها بالا بره. تِک‌بلاگ سحاب سید مرتضی موسوی Sat, 21 Aug 2021 15:39:11 +0430 https://virgool.io/SahabPardaz/%DA%AF%D8%B2%D8%A7%D8%B1%D8%B4-%D8%B3%D8%A7%D9%84%DB%8C%D8%A7%D9%86%D9%87-%D8%AF%DB%8C%D8%AC%DB%8C-%DA%A9%D8%A7%D9%84%D8%A7-%D9%87%D9%88%D8%B4-%D9%85%D8%B5%D9%86%D9%88%D8%B9%DB%8C-%D8%AF%D8%B1-%D8%AE%D8%B1%D8%AF%D9%87-%D9%81%D8%B1%D9%88%D8%B4%DB%8C-%D9%87%D8%A7%DB%8C-%D8%A2%D9%86%D9%84%D8%A7%DB%8C%D9%86-bwjtlcdlea9v افرادی که به شدت به تغییر دنیا فکر می کنند، همان کسانی هستند که این کار را انجام می دهند.امروزه در محافل مختلف به خصوص در کسب‌وکار‌ها حرف از هوش‌مصنوعی زده می‌شود. هوش‌مصنوعی همچون یک مفهوم سهل ممتنع تا به امروز ظهور و بروز داشته است. مدیران، همگی به دنبال استفاده از این تکنولوژی هستند اما هر چه عطش آن‌ها در استفاده از این ابزار بیشتر می‌شود، ابهامات بیشتری در مورد آن پیدا می‌کنند. عدم توقع درست از این ابزار و همچنین نبود زیرساخت‌های داده‌محوری در سازمان می‌تواند موجب سرخوردگی در استفاده از این تکنولوژی شود چرا که هزینه‌های هنگفتی را بر دوش سازمان گذاشته و عملا نتایج مطلوبی نیز در پی نخواهد داشت.انتشار گزارش سالیانه دیجی‌کالا بهانه‌ای شد تا به بررسی استفاده از هوش‌مصنوعی در سازمان‌ها بپردازیم. عملکرد دیجی‌کالا در سال ۹۹ طبق گزارش منتشر‌شده نشان از بهبود کیفیت و رشد سازمان دارد. رشدی که بخشی از آن مرهون استفاده از تکنولوژی‌های نو و به‌روز در دیجی‌کالا ست و نشان از این دارد که دیجی‌کالا توانسته است زیرساخت‌های داده‌محوری را در سازمان خود نهادینه کند و سپس با به‌کارگیری هوش‌مصنوعی عملکرد خود را ارتقا دهد.در فصل «بستر فناوری» در این گزارش، می‌توان مواردی را که دیجی‌کالا از هوش‌مصنوعی و کلان‌داده‌ها استفاده کرده‌است مشاهده کرد. مواردی همچون بهبود موتور جست‌وجو، سیستم پیشنهاد‌دهنده، نظارت بر محتوای نظرات، پیش‌بینی فروش کالا‌های منتخب، شناسایی تقلب در استفاده از کد‌های تخفیف و همچنین بهبود بسته‌بندی از مواردی هستند که دیجی‌کالا نام آن‌ها را ذکر کرده است. اما برای طراحی و توسعه یک سیستم موفق مبتنی بر هوش‌مصنوعی لازم است نکاتی در نظر گرفته شود. نکاتی که می‌توانند در قالب انتظارات مدیران رده‌های بالای سازمان از تیم‌های فنی و توسعه محصول درنظر گرفته شوند. در واقع در عصر داده‌محوری لازم است تا مدیران بدانند که از جعبه‌سیاه هوش‌مصنوعی باید چه انتظاراتی داشته باشند. از طرفی توسعه‌دهندگان نیز باید به‌طور مسئولانه‌ای اقدام به طراحی و توسعه کنند. در شرکت گوگل حدودا یک سال است که برای طراحی و توسعه هوش‌مصنوعی اصول و قواعدی درنظر گرفته شده است که می‌توانید از این بلاگ آن‌ها را مشاهده کنید. این اصول لزوما صرفا فنی نیستند و بعضا از بیرون به موضوع هوش‌مصنوعی نگاه می‌کنند و همین امر باعث می‌شود که قابل فهم برای عموم باشند.در اولین گام لازم است تا مسئله به‌دقت و به‌درستی تعریف شود. اینکه بدانیم دقیقا دنبال چه چیزی می‌گردیم، اولین گام است. در واقع نباید توقع داشته باشیم که یادگیری ماشین و یا هوش‌مصنوعی اینکه چه مسئله‌ای را باید حل کنیم را به ما بگوید بلکه قرار است مسئله‌ای که ما تعریف می‌کنیم را حل کند[1]. دیجی‌کالا در این گام توانسته بخوبی مسئله‌های مشخصی همچون بهبود موتور جست‌وجو یا سیستم پیشنهاد‌دهنده و یا پیش‌بینی فروش کالاهای منتخب را تعریف کند. در گام بعدی لازم است تا با استفاده از تعریف مسئله، معیارهای ارزیابی مشخصی در سطح کسب‌وکار تعریف شود[2]. مسئله‌هایی که در حوزه یادگیری ماشین تعریف می‌شوند، توابع هدفی را بهینه می‌کنند که عموما از فهم کسب‌وکار دور هستند و جنبه ریاضیاتی دارند. این مرحله نقطه‌ای ست که کارشناسان حوزه کسب‌وکار باید با توسعه‌دهندگان همراهی کنند و معیار‌های مشخص و خوش‌تعریفی را در سطح کسب‌وکار تعریف کنند که عموما متاثر از شاخص‌های کلیدی عملکرد در سازمان هستند. مثلا در قسمت شناسایی تقلب در جشنواره‌ها، دیجی‌کالا توانسته است به صرفه‌جویی روزانه صد میلیون تومانی برسد یا در بهبود موتور جست‌وجو نرخ تبدیل ۸ برابری معرفی شده است. این شاخص‌ها یک معیار قابل فهم برای افراد کسب‌وکار است و حس اثربخش‌بودن توسعه یک موتور مبتنی بر هوش‌مصنوعی را متبادر می‌کند. در نبود این معیار‌ها حتی در صورت موثر بودن به‌کارگیری هوش‌مصنوعی باز هم حس موثر بودن القا نمی‌شود. مثلا در همین گزارش و برای پیش‌بینی فروش کالاهای منتخب، معیار عملکردی آورده نشده است که به نظر بهتر است برای این قسمت نیز معیار عملکرد ارایه گردد. همچنین بررسی ابعاد اجتماعی توسعه هوش‌مصنوعی نیز از مسئولیت‌های مهمی ست که مدیران سازمان باید به آن توجه کنند[3]. دیجی‌کالا در قسمت بهینه‌سازی بسته‌بندی نیز به خوبی به این موضوع توجه کرده است و نشان داده که با توسعه یک روش بهبود بسته‌بندی تا چه حد می‌تواند به صرفه‌جویی در منابع طبیعی کمک کند. بخشی از گزارش سالانه دیجی‌کالا. صرفه‌جویی قابل توجه در منابع طبیعی با پیاده‌سازی یک موتور هوش‌مصنوعی برای بهبود بسته‌بندی محصولاتدر واقع هر چقدر سازمان به سمت حرفه‌ای تر شدن پیش می‌رود افق نگاه سازمان در مسائل مهندسی، مسائل اجتماعی را نیز در بر می‌گیرد. به همین جهت شاید در سازمان‌های کوچک، بسیاری از مسائل اجتماعی اصلا محلی از اعراب نداشته باشد اما برای دیجی‌کالا می‌تواند مهم و پرفایده باشد. به عنوان یک پیشنهاد در راستای رسالت اجتماعی، به دیجی‌کالا توصیه می‌کنیم در گزارش‌های سال‌های آتی حتما ذکر کنند که چه مقدار از منابع سخت‌افزاری مانند GPU ها استفاده کرده‌اند چرا که در برخی پژوهش‌ها نشان داده شده است مثلا مدل خاصی از آموزش یک شبکه هوش مصنوعی به نام ترنسفورمر ( که ابتدا از حوزه پردازش زبان طبیعی مطرح شده است) می‌تواند تا ۵ برابر دوره حیات یک اتومبیل کربن‌دی‌اکسید تولید کند[4]!! میزان انتشار گاز دی‌اکسید‌کربن در سناریوهای مختلف. آموزش یک شبکه ترنسفورمری به تنهایی نمی‌تواند میزان زیادی دی‌اکسیدکربن منتشر کند اما چنانچه با مکانیزم neural architecture search همراه شود تا ۵ برابر یک اتومبیل می‌تواند گاز دی‌اکسیدکربن منتشر کند[5]شکل بالا نشان می‌دهد که مثلا برای آموزش یک شبکه ترنسفورمر اگر از مکانیزم neural architecture search استفاده کنیم تا ۵ برابر بیشتر گاز دی‌اکسیدکربن منتشر می‌شود. بنابراین چنانچه یک معماری پیش‌فرض برای شبکه درنظر بگیریم و از این مکانیزم استفاده نکنیم می‌توان به میزان بسیار زیادی از انتشار این گاز جلوگیری کرد و دین خود را بیشتر به طبیعت ادا کنیم! البته که توجه به این موارد در نگاه اول سخت‌گیرانه به نظر می‌رسد اما هرچه سازمان بالغ‌تر شود می‌تواند رسالت‌های اجتماعی بیشتری را برای خود تعریف کند.سوگیری و انصافمبحث سوگیری و انصاف و یا bias & fairness در سال‌های اخیر بسیار مطرح شده است. عبارت bias در واقع اشاره به سوگیری‌های اجتماعی در جامعه موجود دارد که ممکن است در دیتاهایی که برای آموزش مدل‌های مبتنی بر هوش مصنوعی استفاده می‌شود نیز دیده شوند. مثلا در جامعه آمریکا این بایاس وجود دارد که سیاه‌پوستان، بیشتر جرم و جنایت انجام می‌دهند. وجود این سوگیری اجتماعی منفی می‌تواند در داده‌هایی که برای آموزش مدل‌های هوش‌مصنوعی به‌جهت اعتبارسنجی برای اعطای وام‌های بانکی استفاده می‌شود، خود را نشان دهد و مدل آموزش‌داده‌شده را به سمت عدم اعتبار برای سیاه‌پوستان سوق دهد. وجود این پدیده خطرناک با اولین اعتراضات به گوگل‌ترنسلیت شروع شد. زمانی که این ابزار برای ترجمه جملاتی که شغل‌هایی با موقعیت اجتماعی پایین‌تر داشتند از ضمیر "She" استفاده می‌کرد. این نشان می‌داد داده‌هایی که برای مدل‌های زبانی مورد استفاده در این ابزار استفاده شده بودند از سوگیری جنسیتی رنج می‌بردند. از همان زمان شرکت گوگل اصولی را برای طراحی این سیستم‌های مبتنی بر هوش‌مصنوعی درنظر گرفت تا از عدم انصاف و هم‌چنین سوگیری‌های نامتوازن جلوگیری کند[2]. همچنین در recommender system ها نیز می‌تواند نوعی عدم رعایت انصاف وجود داشته باشد. این عدم انصاف عموما در قبال مشتریانی که کمتر خرید انجام داده‌اند در قبال مشتریان پرخرید دیده می‌شود. به نحوی که مشتریان پرخرید عموما پیشنهادهای دقیق‌تری دریافت می‌کنند در حالیکه مشتریانی که فعالیت کمتری دارند پیشنهاد‌های بسیار ضعیفی به آن‌ها می‌رسد[6]. این عدم توازن تحت عنوان عدم انصاف شناخته می‌شود. لازم است تا مدیرانی که از تیم فنی انتظار طراحی مدل‌های هوشمند دارند به مبحث سوگیری و انصاف توجه ویژه کنند و معیارهایی برای بهبود این موارد توسعه دهند. در دیجی‌کالا یکی از موارد استفاده از هوش‌مصنوعی استفاده از سیستم پیشنهاددهنده است که تنها معیاری که از آن در گزارش یاد شده رشد استفاده ۳۰ درصدی از آن است که البته بسیار خوشحال‌کننده است. به نظر لازم است تا دیجی‌کالا در گزارش‌های آتی حتما معیارهای دقیقی را برای سوگیری و انصاف در توسعه و طراحی این سیستم‌ها تعریف کرده و آن‌ها را در گزارش اعلام نماید.سخن آخردر پایان باید به تمام تیم‌های دیجی‌کالا به خصوص تیم فنی آن خسته نباشید بگوییم. همچنین خوشحال باشیم که چنین سازمان بالغی در فضای IT کشور حضور دارد. امیدواریم انتشار این گزارش‌های عمومی ادامه‌دار باشد و همچنین در قسمت‌های مربوط به AI مواردی که در بالا گفته شد نیز در آن وارد شود تا به توسعه فضای هوش‌مصنوعی در کشور کمک کند.پ.ن: گزارش عملکرد سالیانه دیجی‌کالا در سال ۹۹ را می‌توانید از اینجا دریافت کنید.[1]: Human-Centered Machine Learning[2]: Responsible AI practices[3]: Building responsible AI for everyone[4]: Energy and Policy Considerations for Deep Learning in NLP[5]: Training a single AI model can emit as much carbon as five cars in their lifetimes[6]: User-oriented Fairness in Recommendation تِک‌بلاگ سحاب محمدمهدی آقاجانی Sat, 14 Aug 2021 13:57:48 +0430 https://virgool.io/SahabPardaz/%D8%A8%D8%B1%D8%A7%DB%8C-%D8%A7%D8%B1%D8%AA%D9%82%D8%A7%DB%8C-%DA%A9%DB%8C%D9%81%DB%8C%D8%AA-%D8%AA%D9%88%D8%B3%D8%B9%D9%87-%DB%8C-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-%D8%A7%D8%B2-%DA%A9%D8%AC%D8%A7-%D8%B4%D8%B1%D9%88%D8%B9-%DA%A9%D9%86%DB%8C%D9%85-vjiptmwsw5wh کیفیت، مقصدی برای موفقیتامروزه در صنعت نرم‌افزار، کیفیت، امری اجتناب‌ناپذیر برای کاهش هزینه‌ها در بلندمدت و دستیابی به موفقیت در حوزه‌ی فروش شمرده می‌شود. مقوله‌ی اهمیت کیفیت خود موضوع مهمی است که نمی‌خواهم در این‌جا به آن بپردازم؛ اما باید بدانید که کیفیت چیزی نیست که آنرا به یک محصول بیفزایید. محصول باکیفیت نتیجه یک فرآیند تولید باکیفیت است. حال اگر بدنبال تولید یک سیستم نرم‌افزاری هستید که آیتم‌های کیفی مطرح و مدنظر شما را داشته باشد، بهتر است به فکر ارتقای کیفیت توسعه نرم‌افزار خود باشید.اگر توسعه‌ی باکیفیت نرم‌افزار را به عنوان یک هدف میانی قبول دارید، در دنیایی که نظرات متنوعی در این زمینه وجود دارد، بهتر است با توجه به نیازهای خود هدف و مسیر حرکت خود را مشخص کنید. این مسیر و هدف برای شروع کار ضروری است؛ هرچند ممکن است با دریافت داده‌های جدید، اصلاح و تغییراتی در آن اعمال کنیم.یک مدل بلوغ می‌تواند مسیر ما را در رسیدن به این هدف، مدون نماید.گام نخست: در مورد نظرات و تجربه‌های دیگران تحقیق کنیدمعمولا تجربیات شرکت‌های موفق، در قالب کتاب‌هایی توسط افراد شاخص درون آن‌ها، منتشر می‌شود. هرچند این کار با تاخیر و با هدف تبلیغاتی همراه بوده و ممکن است بعضی از نقاط ضعف روش‌های به‌کاررفته را پوشش ندهد-که باید حواسمان به این موارد باشد-؛ ولی مسلما نکات گران‌بهایی در اختیار ما قرار می‌دهد.از دو کتاب How google Tests Software و Continuous Delivery می‌توان به عنوان دو اثر تاثیرگذار در این زمینه نام برد.کتاب How Google Tests Software اثر James Whittaker، Jason Arbon و Jeff Carollo ، تجربیاتی را در زمینه کیفیت نرم‌افزار بیان می‌کنند. چیزی که این کتاب بیان می‌کند - و همانطور که گفتم، ما نیز به دنبال آن هستیم - این است که کیفیت، هنگام تولید نرم‌افزار به دست می‌آید و امکان افزودن آن به نرم‌افزار تولیدشده، وجود ندارد. پس باید در فرایند توسعه‌ی نرم‌افزار به دنبال تولید کیفی نرم‌افزار باشیم.در کتاب Continuous Delivery، اثر Jez Humble و David Farley نویسندگان سعی دارند توسعه‌دهنده را از برزخ استقرار و تحویل دور کنند؛ نه بدان معنا که این وظایف را به اشخاص دیگری واگذار کنند، بلکه برعکس، همه‌ی کارها بدون سیلوبندی، در تیم توسعه و با محوریت محصول صورت می‌گیرد. هدف نهایی در این‌جا استقرار محصول فقط با فشار یک دکمه است.گام دوم: آیتم‌های کیفی را شناسایی کنیدوقتی در مورد کیفیت توسعه‌ی نرم‌افزار صحبت می‌کنیم، آیتم‌های متعددی به ذهنمان می‌رسد که می‌توانیم براساس آن‌ها، خود را از لحاظ حرکت در مسیر صحیح ارزیابی کنیم. برای مثال، چقدر تست برای کدهای خود داشته باشیم، چقدر به خودکارسازی فرآیندها اهمیت دهیم و … ؛ اما نکته‌ای که وجود دارد این است که اکثر این موارد مطلق نبوده و بعضا به تنهایی چیز خاصی را به ما نشان نمی‌دهند. در مورد این آیتم‌ها، اهمیت آن‌ها و آستانه‌هایی (threshold) که برای آن‌ها در نظر می‌گیریم، نظرات متعددی وجود دارد. بنابراین بهتر است نظرات مختلف را جمع‌آوری و بر اساس نیازهای خود در مورد آن‌ها تصمیم بگیریم.گام سوم: گام‌ها را مشخص کنیدحال که آیتم‌های کیفی مد نظر خود را می‌دانیم، برای دستیابی به آن‌ها باید گام‌هایی را طراحی کنیم. آیتم‌ها معمولا دو شکل دارند: یک دسته، آن‌هایی که با مقادیر دو-دویی ارزیابی می‌شوند، مانند وجود و عدم وجود. دسته‌ی دیگر، آن‌هایی که برای آن‌ها می‌توان بازه‌های مقادیر درنظر گرفت، از قبیل بازه‌هایی از درصدها.اگر شما بخواهید در مسیر طراحی شده و با گام‌های در نظر گرفته شده قدم بردارید، دوست دارید چگونه پیشرفت کنید؟ اگر برای اولین گام و تحقق آیتم‌های آن به زمان قابل توجهی نیاز داشته‌ باشید، حاضرید وارد این بازی شوید؟ شاید نه. پس بهتر است گام‌ها را از کوچک به بزرگ طراحی کرده تا انگیزه‌ها را برای ادامه کار تقویت کنید.مسلما با قانون ۸۰/۲۰ یا اصل پارتو آشنایی دارید؛ اصلی که طبق آن در اکثر رویدادها، تقریبا ۸۰ درصد از اثرات از ۲۰ درصد از علل، ناشی می‌شود. پس بهتر است یکی از گزینه‌هایمان در اولویت‌دهی آیتم‌ها، برداشتمان از میزان تاثیر آن‌‌ها در بهبود کیفیت فرایند باشد. آیتمی که به نسبت هزینه‌ی صرف‌شده، بهبود بیشتری را در پی دارد، شایسته‌ی قرارگیری در گام‌های اول است؛ البته اگر آیتم دیگر در آن گام یا گام‌های بعدی، پیش‌نیاز آن نباشد.مسیر «کارنگی ملون» الهام بخش ما«مدلی برای بهینه‌سازی پروسه‌های تولید» شاید تعریف مختصر و مفیدی برای CMMI باشد؛ مدلی که به ادعای دانشگاه کارنگی ملون، می‌تواند برای هدایت بهبود فرایند در یک پروژه، بخش یا کل سازمان استفاده شود. CMMI را شاید بتوان مشهورترین مدل بلوغ فرایندی در جهان دانست. اجرای CMMI برای بسیاری از پروژه‌های دولتی ایالات متحده، به خصوص در حوزه‌ی نرم‌افزار، اجباری است. مدل CMMI، راهنمایی برای توسعه یا بهبود فرایندها برای دستیابی به اهداف کسب‌وکار یک سازمان، فراهم می‌کند.ارزیابی CMMI به شناسایی نقاط قوت و ضعف فرآیندهای سازمان و بررسی ارتباط نزدیک فرایندها با بهترین روش‌های (‌best practice) CMMI کمک می‌کند.چرا از همین مدل استفاده نکنیم؟همان‌طور که می‌بینید CMMI یک مدل بلوغ سازمانی است؛ پروسه‌های سازمانی را مدنظر قرار می‌دهد و بازیگران و تصمیم‌گیران آن در سطح سازمان هستند؛ ولی ما به دنبال یک مدل هستیم که در جنبه‌های فنی، ما را راهنمایی کرده و توسط بازیگران فنی هدایت و در سطح محصول پیاده‌سازی شود. آن‌چه که مورد توجه ما باید قرار بگیرد، روش مدل‌سازی مسیر بلوغ بوده که شامل سطوح و حوزه‌ها و آیتم‌های کیفی است و به صورت مشابه مورد استفاده‌ی ما قرار گرفته‌ است.نظرات افراد تاثیرگذار به ما کمک می‌کنددر هر تیم به نسبت پروژه‌هایی که انجام شده و حوزه‌ای که روی آن کار شده، افراد با تجربه‌ای حضور دارند که حین کار مشکلات را مشاهده کرده‌اند. اگر یافتن مسیر، از طریق فکر جمعی جلو برود، راهی ترسیم خواهد شد که در عمل تناسب ضمنی با ماهیت پروژه‌ها خواهد داشت.تعادل آرمان‌گرایی و عمل‌گرایی را حفظ کنیددرست است که در حال ترسیم راه بلوغ کیفیت هستیم؛ اما رسیدن به بهترین راه در اولین تلاش شاید خیلی خوشبینانه باشد؛ پس سعی نکنید همه چیز بدون عیب و نقص باشد. برای رسیدن به بهترین راه شاید لازم باشد قدم در راه گذاشته و در عمل طراحی خود را بیازمایید.هیئت ژوری را برای اصلاحات حفظ کنیدارزیابی یک محصول در دستیابی به سطوح کیفی و بررسی اصلاحات پیشنهادی، کاریست که باید به صورت مداوم صورت بگیرد. پس هیئتی که در طراحی مدل دخیل بوده‌اند، بایستی حفظ شوند. مسلما اعضای هیئت تغییر می‌کنند، ولی ساختار باید حفظ شود. من اسم این هیئت را «کمیته‌ی کیفیت» می‌گذارم.انعطاف را وارد طراحی خود کنیدطراحی مدلی که برای تمام پروژه‌ها جواب‌گو باشد، شاید امری غیر ممکن باشد؛ پس می‌توان به درخواست تیم توسعه‌دهنده‌ی محصول و تایید کمیته‌ی کیفیت، اجرای یک یا چند مورد را در یک سطح کیفی معلق نمود. این موارد می‌تواند مواردی باشد که برای آن محصول خاص موضوعیت نداشته یا مثلا آن محصول یک مورد را از سطح بالاتر - که این مورد را نیز پوشش می‌دهد - با هزینه ارزیابی پایین‌تر، به انجام رسانده‌ است.تجربه‌ی ماما در سحاب‌ این مسیر را با هم‌فکری یکدیگر طی کرده و در حال حاضر مدلی در اختیار داریم که نقشه‌ی راه ما در مسیر توسعه‌ی نرم‌افزار باکیفیت است. البته همان‌طور که گفته‌شد، همواره برای دریافت نظرات جدید آماده‌ایم. در همین راستا این مدل به صورت عمومی منتشر شده‌ است و در مسیر زیر می‌توانید بدان دسترسی پیدا کنید:https://git.qualitic.irفاصله‌مان تا مقصد چقدر استخوب است بدانید چقدر تا هدف یا مقصد فاصله دارید. ابزارهایی که به ما در مسیر ارتقای کیفیت کمک می‌کنند، متعدد هستند. چطور است ابزاری در اختیار بگیریم که داده‌ی سایر ابزارهایمان را به صورت متمرکز، نمایش و وضعیت دستیابی به اهداف را به ما نشان دهد؟ استفاده از این ابزار، به دلیل قابلیت‌هایی از جمله نمایش سیر پیشرفت، می‌تواند انگیزه‌ی بیشتری را در جهت ارتقای کیفیت محصول، در تیم توسعه تزریق کند. در سحاب بعد از طراحی مدل بلوغ، به دنبال توسعه‌ی چنین ابزاری رفتیم. ابتدا راه‌حلی برای نمایش وضعیت آن دسته از آیتم‌ها که ابزار سنجش خودکار برای آن‌ها وجود نداشت، تمرکز کرده و بعد از آن به سراغ تجمیع داده‌ی سایر ابزارها رفتیم. این ابزار که نام آن را «نمو» گذاشتیم، هرچند در حال حاضر یک ابزار خصوصی در سحاب‌ است، ولی شاید در آینده‌ای نزدیک، امکان استفاده از سرویس‌های آن برای علاقه‌مندان فراهم شود.حرف آخرآنچه بیان شد بخشی از مسیر حرکت و نکات تجربی ما در سحاب برای عجین کردن کیفیت در محصولات و در حین تولید آنها بود؛ اما بدانید هیچ قسمتی از این نقشه‌ی راه بدون باور عمومی افراد به ضرورت کیفیت و ضرورت اعمال آن در پروسه‌ی تولید، تحقق نمی‌یابد. تِک‌بلاگ سحاب سعید دهقان Sat, 17 Apr 2021 11:03:12 +0430 https://virgool.io/SahabPardaz/why-dont-we-test-mw1knems3l01 از موارد استثنا که بگذریم، معمولا برنامه‌نویس‌های تازه‌نفس اشتیاق زیادی به نوشتن تست برای کدهایشان ندارند. خیلی از بحث‌ها در تیم‌های توسعه نیز ناظر به همین موضوع است: چرا باید تست بنویسیم؟ چقدر تست بنویسیم کافی است؟ چرا اینجا لازم نیست تست بنویسیم؟ و ...مطالب مختلفی در مورد راه‌های اصولی نوشتن تست وجود دارد؛ لذا در این مقاله به جای پرداختن به آن‌ها، تلاش شده تا به دلایلی که باعث می‌شود کمتر سراغ تست برویم، اشاره شود و درک بهتری از شرایط حاصل گردد. همچنین در ادامه، راه‌هایی برای بهبود این شرایط پیشنهاد خواهد شد.«تست کردن» یا «تست نوشتن»؟ مسئله این استاگر اولین لحظه‌ای که توانستید دستوری را - در قالب متن - به کامپیوتر بفهمانید به خاطر بیاورید، احتمالا حس فوق‌العاده‌ی پس از آن را هم به خاطر خواهید آورد؛ شما نه به آن دلیل که توانسته‌اید متنی را تایپ کنید، بلکه به خاطر اینکه توانسته‌اید آن را تست کنید، هیجان‌زده شدید. نکته دقیقا اینجاست! تازه‌کارترین برنامه‌نویس‌ها هم هرگز فراموش نمی‌کنند «برنامه‌ای که به تازگی نوشته‌اند» را تست کنند، بلکه صرفا دلیلی نمی‌بینند آن را در قالب کد مکتوب کنند؛ زیرا:مطمئن هستند کد کنونی درست کار می‌کند. مخصوصا مواقعی که قسمت کاملا جدیدی را توسعه داده‌اند؛ چراکه در فرایند توسعه، بارها و بارها عملکرد مورد نظرشان را به صورت دستی تست کرده‌اند.مطمئن هستند آنچه قرار است به عنوان تست بنویسند، پاس می‌شود؛ لذا انگیزه‌ای برای صرف وقت و نوشتن «کدی که نتیجه‌اش مشخص است» ندارند.ترجیح میدهند وقتی را که صرف نوشتن تست می‌کنند، به توسعه‌ی قابلیتی جدید و یا رفع یک مشکل دیگر اختصاص دهند.ممکن است نوشتن تست فرایند پیچیده، زمانبر و یا مبهمی برای آن‌ها باشد.ممکن است با خود بگویند اصلاً چه کسی می‌خواهد این تست را اجرا کند؟ممکن است تست را وظیفه‌ی فرد یا تیم دیگری بدانند.درباره هر یک از مسائل یاد شده می‌توان دلایل متقابل آورد (چنانچه آورده‌اند) و توضیح داد که چرا نوشتن تست با وجود این دلایل، غالبا سودمند است. اما به نظر می‌رسد مسئله بیشتر به تجربه مرتبط باشد تا دانش؛ توسعه‌دهنده‌ای که بر نوشتن تست اصرار می‌ورزد، احتمالا بیش از آنچه مزایای کوتاه‌مدت و بلندمدت این کار را «مطالعه» کرده باشد، «تجربه» کرده است. این همان دلیلی است که باعث می‌شود توسعه‌دهندگانِ باتجربه‌تر با اطمینان و لذت بیشتری تست بنویسند، تا برنامه‌نویسان تازه‌نفس.در ادامه به مواردی خواهیم پرداخت که به کمک آنها بتوان نوشتن تست را برای همه بامعناتر کرد.جذابیت‌هایی که در ابتدا دیده نمی‌شوندراستش را بخواهید، گاهی حق با برنامه‌نویس‌های تازه‌نفس است! اما مشکل اینجاست که آنها احتمالا دلایل اصلیِ بیهوده بودن تست را بیان نمی‌کنند. وقتی تست‌ها به صورت خودکار اجرا نمی‌شوند، عملا تبدیل به کدهای یکبارمصرف می‌شوند. یا وقتی فرایند بعد از تست (نظیر انتشار، استقرار، تست‌های non-functional و ...) همچنان به صورت دستی است و هیچ رویّه‌ی مشخصی ندارد، چه انگیزه‌ای برای مشخص کردن فرایند تست به تنهایی وجود دارد؟در مقابل، وقتی همه یا بخشی از چرخه‌ی تولید نرم‌افزار خودکار است (به این معنا که فرایند آن مشخص و قابل اجرا توسط کامپیوتر است)، وجود تست‌هایی که آن‌ها هم به صورت خودکار بتوانند به اطمینان از درستی مراحل بعدی کمک کنند، جذاب‌تر خواهد بود.از موارد بالا که بگذریم، نوشتن تست جذابیت‌هایی دارد که مشاهده‌ی آن‌ها نیازمند گذر زمان است. برخی از این موارد به شرح زیر است:۱. وقتی بر روی یک قابلیت یا رفع ایراد تمرکز کرده‌اید، ممکن است از تأثیر آن بر زوایای دیگر محصول غافل باشید. اینجاست که تست‌هایی که قبلا برای آن زوایا نوشته‌اید، به دادتان میرسند.تست‌ها، زمانی که شکست می‌خورند ارزش واقعی خود را نشان می‌دهند؛ نه زمانی که پاس می‌شوند!۲. شرایطی را در نظر بگیرید که بتوان تنها با فشار یک دکمه، نسخه جدیدی از برنامه را منتشر کرد. در این شرایط وجود تست‌های ریز و درشت، مخصوصا زمانی که با کاربران متعدد یا سخت‌گیر مواجهید، این قوّت قلب را به شما می‌دهد که احتمالا آن دکمه قرار نیست روزگارتان را سیاه کند!تست‌ها به همان اندازه که مانع خوشحالی تیم از ارائه سریع‌تر محصول می‌شوند، مانع ناراحتی آن‌ها از شکست محصول به دلیل سهل‌انگاری یا غفلت خواهند شد.۳. «این مشکل را قبلاً دیده بودم»، «دوباره همان حالت پیش آمده»، «این را مگر حل نکرده بودیم؟!» و جمله‌های مشابه غالبا به این علت بیان می‌شوند که هنگام حل یک ایراد، برای آن تست نمی‌نویسیم و لذا بعداً به دلایل مختلف دوباره با آن مواجه می‌شویم.نوشتن تست برای ایرادات، در واقع نوعی مستند کردن آن‌هاست؛ مستندی دقیق، پویا و قابل اجرا.۴. علاوه بر موارد فوق، نوشتن تست خود باعث دقیق شدن مسئله و توجه به زوایای مختلفی می‌شود که لزوما هنگام پیاده‌سازی راه‌حل به ذهن توسعه‌دهنده نمی‌رسند. بارها رخ داده است که برخی تست‌هایی که بعد از توسعه‌ی یک قابلیت جدید نوشته می‌شوند - در کمال ناباوریِ توسعه‌دهنده - شکست می‌خورند!جذابیت‌هایی که باید ایجاد شوندمسئله‌ای که ممکن است ما را در مقابل نوشتن تست تنبل کند، عدم جذابیت این کار است. اگر از زاویه‌ی فلسفه‌ی لذت‌گرایی به موضوع نگاه کنیم، نوشتن تست، علاوه بر فواید بلندمدت، باید لذت‌های کوتاه‌مدت نیز به همراه داشته باشد؛ این نکته در نگاه اول ممکن است بی‌اهمیت جلوه کند؛ اما تجربه خلاف آن را نشان می‌دهد.در ادامه به برخی نکات کوچک که به این جذابیت کمک می‌کنند اشاره می‌شود. این نکات در عین جذابیت کوتاه‌مدت، برکات بزرگ‌تری نیز به همراه خواهند داشت که توضیح آن در این مجال نمی‌گنجد.ساده کردن فرایند تستگاهی علت تنبلی در نوشتن تست، پیچیدگی و حجم کار غیرطبیعی در پیاده‌سازی آن است.چارچوب‌های رایج تست معمولا بسیاری از پیچیدگی‌های عمومی آن را به عهده می‌گیرند (مواردی نظیر ایزوله بودن تست‌ها از هم، پاک کردن داده‌ها بعد از تست، نمایش نتایج، علت شکست‌ها و ...). اگر مواردی هستند که همچنان نویسنده‌ی تست را با حجم زیادی از کد تکراری یا پیچیده روبرو می‌کنند، این مسئله را به طور جداگانه حل کنید. یا از کسانی که به طور پیش‌فرض با نوشتن تست خوشحال هستند بخواهید بیشتر تست بنویسند!If it hurts, do it more frequently!Jez Humbleبرای مطالعه‌ی بیشتر در این باره به اینجا مراجعه کنید.محاسبه و نمایش میزان پوشش تست (Test Coverage)تقریبا تمامی ابزارهای اجرای تست، میزان پوشش تست را نیز می‌توانند محاسبه کنند و یا دست‌کم گزارش‌هایی تولید می‌کنند که ابزارهای دیگری نظیر SonarQube یا CodeCov برای محاسبه با آن‌ها آشنا هستند.اما مسئله مهم در اینجا محاسبه نیست، بلکه نمایش مقدار محاسبه شده است. سعی کنید میزان پوشش کد را در محل‌هایی که بیشتر در چشم هستند، نمایش دهید. یک نشان (badge) در مخزن پروژه، یک قسمت کوچک از مانیتور عمومی در تیم و ... می‌تواند جای مناسبی برای نمایش پوشش کد باشد.چراغ تست!اگر اهل زیاده‌روی هستید، وجود یک چراغ فیزیکی که نشانگر pass یا fail بودن تست‌ها در شاخه‌ی اصلی مخزن کد است، می‌تواند جذاب باشد. به این صورت که هنگام موفق بودن تست‌ها چراغ سبز، و به محض شکست آن‌ها قرمز شود.وقتی چراغ قرمز است توقف کنید؛ همه‌ی کارهایتان را رها کنید و به رفع مشکلی که پیش آمده بپردازید. طبق توصیه‌ای که در کتاب Continuous Delivery بیان شده، اولویت اول تیم، پاس نگهداشتن پایپلاین است.وقتی چراغ سبز است با خیالی آسوده به کارهای دیگر خود ادامه دهید.نمایش پوشش تست به صورت عینییک قابلیت فوق‌العاده که اخیرا در گیت‌لب اضافه شده است، امکان مشخص کردن خطوط پوشش‌داده‌شده در MergeRequestهاست؛ به این صورت که در کنار خطوط کد، این که هر خط در تست‌ها پوشش داده شده یا خیر با رنگ سبز و زرد نمایش داده می‌شود. جزئیات بیشتر در این باره را می‌توانید در اینجا مشاهده کنید.درگیر کردن تست در برنامه‌ریزی‌های زمانیدر جلسه‌ی برنامه‌ریزی اسپرینت (sprint planning) نشسته‌اید و مشغول تخمین زمان مورد نیاز برای انجام یک کار هستید. هرکس دلایل خود را برای زمانی که تخمین زده است، مطرح می‌کند. مدیر تیم به این اشاره می‌کند که از نظر او آن کار به علاوه‌ی زمان مورد نیاز برای تستش به فلان مقدار زمان نیاز دارد.شاید ساده به نظر برسد؛ اما همین جمله‌ی ساده، باعث می‌شود فشار زمانی که توسعه‌دهنده حین انجام یک کار حس می‌کند کمتر شده و با احتمال و اشتیاق بیشتری به نوشتن تست بپردازد.تعیین اهداف برای میزان پوشش تست‌هاما در سحاب یک پلکان بلوغِ توسعه‌ی محصول داریم که مراحل مختلف برای رسیدن به سطوح بالاتر کیفیت، در آن مشخص شده است. چندین آیتم از این پلکان، مربوط به انواع تست و ویژگی‌هایی مربوط به آنها (نظیر پوشش کد، پوشش نیازمندی و...) است.همچنین برای اینکه وضعیت هر محصول در این پلکان مشخص و شفاف باشد، «نمو» را توسعه داده‌ایم. نمو ابزاری است که به تیم‌ها کمک می‌کند تا سطح کنونی محصول خود را مشاهده و برای ارتقای آن برنامه‌ریزی کنند.این موضوع باعث شده مفهوم تست در شرکت ارزشمندی خود را بیش از پیش نشان دهد.مخلص کلام!خلاصه‌ی کلام اینکه سعی کنید تست‌ها دیده شوند! بهانه‌های درگیر شدن با نتیجه‌ی تست‌ها را زیاد کنید. آن‌ها هرچه بیشتر در کانون توجه قرار بگیرند، اشتیاق تیم برای تولیدشان بیشتر خواهد بود و در نهایت، وقتی تیم‌ها با فواید بلندمدت تست مواجه شوند، دیگر صورت مسئله‌ی «چرا تست نمی‌نویسیم؟» پاک شده است! تِک‌بلاگ سحاب عمران باتمان‌غلیچ Sat, 06 Mar 2021 11:17:50 +0330 https://virgool.io/SahabPardaz/%D8%B3%D8%A7%D8%AE%D8%AA-api-%D9%85%D8%AF%D8%B1%D9%86-%D8%A8%D8%A7-graphql-%D8%A8%D8%AE%D8%B4-%D8%AF%D9%88%D9%85-ewxcofo288mz در بخش قبل گرف‌کیوال رو معرفی کردیم و گفتیم که چه مشکلاتی رو حل می‌کنه، در این بخش با استفاده از Django و Graphene یک ای‌پی‌آی گرف‌کیوال خواهیم ساخت. البته بیشتر توجه روی بخش گرف‌کیوال خواهد بود و فرض می‌کنیم شما با Django آشنایی دارید.این پروژه در این آدرس در دسترس عموم قرار دارد.راه‌اندازی ای‌پی‌آی گرف‌کیوالنصب grapheneابتدا با استفاده از دستور زیر کتاب‌خانه‌ی graphene-django را نصب می‌کنیم:pip install graphene-djangoو در فایل settings.py تغییرات زیر را اعمال می‌کنیم:در قسمت INSTALLED_APPS اپ graphene_django را اضافه کردیم.در انتهای فایل، خط‌های زیر را اضافه می‌کنیم. این چند خط به گرافین می‌گه از کجا ساختار اسکیما رو بخونه.تعریف اسکیماگرافین در پکیج graphql_api.schema دنبال متغیر schema خواهد گشت، مشابه ایمپورت‌ها در پایتون. بنابر این پوشه‌ی graphql_api/schema رو ایجاد می‌کنیم و توش چند تا فایل زیر رو می‌سازیم:تا به اینجا یه کوئری خیلی ساده تعریف کردیم. توی این کوئری تعریف کردیم که یه فیلد وجود داره به نام hello که تایپش String هستش، بعدش هم گفتیم که هر وقت کسی مقدار این فیلد رو خواست، در جواب رشته‌ی world رو برگردونه.روش کار graphene به این صورت است که برای هر فیلدی که تعریف می‌کنیم به دنبال تابعی می‌گردد که با resolve شروع شود و در ادامه نام فیلد بیاید. به طور مثال برای فیلد hello به دنبال تابع resolve_hello می‌گردد و هنگامی که بخواهد کوئری گرف‌کیوال را اجرا کند و مقدار hello را بداند این تابع را صدا می‌کند.افزودن graphql به routingحالا لازمه که یه url تعریف کنیم تا بتونیم به ای‌پی‌ای گرف‌کیوال دسترسی داشته باشیم. فایل urls رو به شکل زیر تغییر می‌دیم تا ای‌پی‌آی graphql در آدرس /gaphql/ دیده بشه:سرور رو اجرا می‌کنیم و به آدرس localhost:8000/graphql می‌ریم تا ببینیم ای‌پی‌آی چطور کار می‌کنه. توی قسمت سمت چپ کوئری graphql رو که می‌خوایم اجرا بشه رو می‌نویسیم و جواب سرور رو دریافت می‌کنیم.سمت راست: جواب سرور، سمت چپ: درخواستبرای اینکه اسکیمای گرف‌کیوال رو به صورت فایل داشته باشیم دستور زیر رو اجرا می‌کنیم:python manage.py graphql_schema --out schema.graphqlو فایل schema.graphql ایجاد می‌شه، و فایل اسکیمای ساخته شده رو در اختیار تیم‌های دیگه قرار می‌دیم که قراره از این ای‌پی‌ای استفاده کنند.اسکیمای hello worldتعریف ای‌پی‌آی مربوط به مدلتا به اینجای کار یه اسکیمای خیلی ساده ساختیم، در ادامه چندتا مدل می‌سازیم و براشون تایپ‌های گرف‌کیوال را تعریف می‌کنیم.تعریف مدل‌های Post و Commentدو تا مدل Post و Comment را به این شکل تعریف می‌کنیم:مدل پست و کامنتتعریف تایپ Postحالا می‌خوایم Post رو به گرف‌کیوال اضافه کنیم، برای این کار لازمه دو تا کار انجام بشه:تعریف تایپ متناظر با مدل Post.تعریف کوئری که بتونیم یک پست رو با آی‌دی بگیریم.تعریف تایپ متناظر با مدل postاین چند خط داره می‌گه که متناظر مدل Post یک تایپ گرف‌کیوال وجود داره و فیلد‌های id و title و body یک پست قابل کوئری کردن هستند. گرفین به صورت اتوماتیک خودش تایپ‌های مدل رو بررسی می‌کنه و تایپ‌های متناظر رو در گرف‌کیوال برای این فیلد‌ها تعیین می‌کنه.حالا باید به کوئری اصلی یه فیلد post اضافه کنیم که id رو ورودی می‌گیره و در صورتی که پست متناظر با این آی‌دی وجود داشت، مقدار پست رو بر می‌گردونه. برای این کار یه کلاس جدید تعریف می‌کنیم:تعریف کوئری مربوط به پستدر این چند خط یک کلاس PostQuery تعریف کرده‌ایم. در این کلاس گفتیم که یک فیلد پست وجود دارد که یک آرگیومنت از نوع ID ورودی می‌گیرد و در خروجی PostType بر می‌گرداند (تایپ گرف‌کیوال متناظر با مدل Post) و سپس تابع resolve_post را تعریف کرده‌ایم این تابع از ورودی id رو می‌خونه و با استفاده از امکانات مدل جنگو، پست رو پیدا می‌کنه و بر می‌گردونه.حالا باید به کوئری اصل اضافه بشه:اضافه کردن کوئری مربوط به پست به کوئری اصلیبا اضافه کردن PostQuery به کلاس‌های پدر Query اصلی، فیلد post به Query اصلی اضافه می‌شود.حال ای‌پی‌آی رو تست می‌کنیم:در این حالت اسکیمای جدید ما به این شکل می‌باشد:یه تایپ جدید به نام PostType اضافه شده است، هم‌چنین فیلد post به کوئری اصلی اضافه شده است.تعریف رابطه‌هاتا به اینجای کار یک تایپ جدید با فیلد‌های ساده ایجاد کردیم، اما در بسیاری از موارد فیلدهای پیچیده نیاز داریم. به طور مثال یک پست، فیلد نویسنده دارد. هم‌چنین لازم است بتوانیم لیست کامنت‌های مربوط به پست را نیز بگیریم. در ادامه این نوع فیلد‌ها را بررسی می‌کنیم.ابتدا دو تایپ گرف‌کیوال برای یوزر و کامنت تعریف می‌کنیم:حال نویسنده و لیست کامنت‌ها رو به پست اضافه می‌کنیم:مقدار self در تابع resolve_comments یک پست است که از مدل Post ایجاد شده است (در این مثال دقیقا همان پستی است که از تابع resolve_post در PostQuery برگردانده شده است). بنابر این می‌توانیم از تمام امکاناتی که مدل جنگو در اختیار ما قرار می‌دهد استفاده کنیم، مثلا لیست کامنت‌ها رو بگیریم و حتی در صورت نیاز، فیلتر کنیم.حالا می‌توانیم دیتای مربوط به کامنت‌ها و نویسنده را از پست بگیریم:تا به اینجا اسکیمای ما شامل تایپ کامنت، یوزر و پست می‌باشد:پیشنهاد می‌کنم در ادامه مستندات graphql و مستندات graphene رو مطالعه کنید تا برای بخش‌های بعدی آماده باشید. جمع بندیتا به اینجای کار یک ای‌پی‌آی ساده‌ی گرف‌کیوال رو راه‌اندازی کردیم و چند تا تایپ هم توش تعریف کردیم و با مفاهیم اولیه گرف‌کیو ال آشنا شدیم. در بخش‌های بعدی مفاهیم پیشرفته‌تری رو توضیح خواهم داد. تِک‌بلاگ سحاب سید مرتضی موسوی Mon, 22 Feb 2021 16:30:12 +0330 https://virgool.io/SahabPardaz/%D8%B3%D8%A7%D8%AE%D8%AA-api-%D9%85%D8%AF%D8%B1%D9%86-%D8%A8%D8%A7-graphql-%D8%A8%D8%AE%D8%B4-%D8%A7%D9%88%D9%84-hgz8kp3pjcbw تا حالا شده وسط پیاده‌سازی کد، اعضای تیم مجبور بشن چندین بار از هم بپرسند که جزئیات رِست (Rest) ای‌پی‌آی چیه؟ و مجبور بشید برید وسط کدها بگردید تا پارامترهای ای‌پی‌آی رو پیدا کنید تا به هم‌تیمی‌تون بگید چجوری باید درخواست بده؟ یا اینکه کد ای‌پی‌آی عوض شده و هماهنگی‌ها به درستی انجام نشده و محصول به مشکل خورده؟ گرف‌کیوال می‌تونه بسیاری از این مشکلات رو کم کنه و به شما کمک کنه با اطمینان محصول توسعه پیدا کنه و تجربه‌ی توسعه (DX، Developer Experience) و حتی تجربه‌ی کاربری (UX) بهتری داشته باشید. در ادامه به بررسی گرف‌کیوال خواهیم پرداخت.گرف‌کیوال چیست؟گرف‌کیوال، یک استاندارد است که یک زبان کوئری تعریف می‌کنه. یک اسکیما برای یک ای‌پی‌آی گرف‌کیوال تعریف می‌شه و بر اساس اون اسکیما کوئری‌ها به سرور زده می‌شه و جواب کوئری‌ها بر می‌گرده. اسکیما شامل همه‌ی اطلاعات لازم برای توصیف ای‌پی‌آی هستش: انواع تایپ‌ها، نام و تایپ فیلد‌ها، و حتی مستندات و توضیحات مناسب برای انسان. برای نمونه یه اسکیما این شکلی هستش:اسکیمای نمونهچرا گرف‌کیوال؟در ابتدا تعدادی از مشکلاتی که ای‌پی‌ای‌های رِست (Rest) داشتند رو توضیح می‌دم، بعدش می‌گم که گرف‌کیوال چجوری این مشکلات رو حل می‌کنه.مشکل over-fetchingدر هنگام استفاده از ای‌پی‌آی‌های رِست خیلی وقت‌ها سرور دیتای اضافه به ما بر می‌گردونه که هم میزان مصرف شبکه رو زیاد می‌کنه و هم بار اضافی روی سرور داره، مثلا شما لیست کتاب‌ها رو از سرور می‌گیرید، اطلاعات عنوان کتاب و نام نویسنده رو نیاز دارید، ولی سرور اطلاعت اضافه زیادی برای شما می‌فرسته که هیچ وقت استفاده نمی‌کنید، مثلا سال چاپ، آی‌دی انتشارات و حتی متن پشت جلد!در گرف‌کیوال، کلاینت دقیقا می‌گه چه فیلدهایی رو نیاز داره و سرور تنها اون اطلاعت رو ارسال می‌کنه. مثلا در صفحه‌ی لیست کتاب‌ها فقط به عنوان نیاز دارید و در صفحه جزئیات کتاب، اکثر فیلدها رو درخواست می‌دید و در هر صفحه تنها به اندازی کافی دیتا دریافت می‌کنید.مشکل under-fetchingدر هنگام استفاده از ای‌پی‌آی‌های رِست خیلی وقت‌ها سرور دیتای کافی به ما بر نمی‌گردونه، مثلا دیتای لیست کتاب‌ها رو فرستاده، ولی نام نویسنده رو نداده و صرفا آی‌دی نویسنده رو برای ما ارسال کرده، در این صورت ما مجبوریم دوباره یه درخواست جدید بدیم و جزئیات اطلاعات نویسنده رو بگیریم و از توش نام نویسنده رو پیدا کنیم تا بتونیم به درستی نمایش بدیم. این باعث می‌شه برای نمایش کامل اطلاعات چندین درخواست به سرور ارسال بشه.در گرف‌کیوال، امکان کوئری زدن دیتا‌های مرتبط وجود داره، یعنی کلاینت می‌گه عنوان کتاب و نام نویسنده رو نیاز دارم و کل دیتا در یک درخواست به دست کلاینت می‌رسه:کوئری نمونهپاسخ سرورمشکل حدس زدن و عدم اطمینانفرض بگیرید یک ای‌پی‌آی رِستی وجود دارد که اطلاعات مربوط به پست‌ها و کامنت‌های یک بلاگ رو در اختیار شما قرار می‌ده. و شما قصد دارید لیست پست‌ها رو بگیرید، دقیقا باید به کجا درخواست بدید؟ احتمالا درخواست باید به ‎/api/posts زده بشه، اگه بخواید یه تک پست رو دریافت کنید چطور؟ ‎/posts/45 هستش یا ‎/post/45 و لیست کامنت‌های یک پست از کجا می‌آد؟ ‎/posts/45/comments و یا یه روش دیگه؟الان یه پست چه مقادیری رو به من بر می‌گردونه؟ عنوان در چه فیلدی هستش؟ title یا post_title یا postTitle یا ... آیا متن پست در پاسخ سرور هستش یا صرفا خلاصه پست اومده؟ آیا تعداد کامنت رو هم می‌ده؟اگه در آینده یکی از این فرضیات عوض بشه چی؟ چه زمانی و به چه طریقی قراره بفهمیم، آیا توسعه‌دهنده‌ی backend شخصا به توسعه‌دهندگان frontend باید خبر بده؟البته برخی از این مشکلات با روش‌هایی مثل استفاده از swagger قابل حل هستند، ولی هم زحمت پیاده‌سازی‌اش وجود داره، و خیلی وقت‌ها هم واقعا کسی همت نکرده و کلا وجود نداره.اما در گرف‌کیوال همه‌ی درخواست‌ها به یک end-point می‌ره، هم‌چنین از ابتدا مفهوم اسکیما (schema) وجود داشته که می‌گفته دقیقا چه تایپ‌هایی وجود داره، هر تایپ چه فیلد‌هایی داره و تایپ هر فیلد چیه و این امکان وجود داره که برای هر فیلد مستندات و توضیحاتی اضافه کنید. دیگه لازم نیست اسم فیلد‌ها حدس زده بشه.حتی ابزارهای مختلفی وجود داره که در هنگام توسعه بر اساس اسکیما راهنمایی می‌کنند که چه فیلد‌هایی وجود داره. هم‌چنین می‌شه در زمان کامپایل و قبل از اجرای برنامه صحت کوئری‌ها بررسی بشه. و برای زبان‌هایی مثل typescript و یا kotlin که تایپ رو پشتیبانی می‌کنند، تایپ‌های متناظر با کوئری ساخته می‌شه و هنگام استفاده از پاسخ سرور با اطمینان کامل کد می‌زنیم.هم در سرور و هم در کلاینت کاملا مطمئن هستیم تایپ ورودی‌های سرور و پاسخ سرور مطابق اسکیما هستش و از این نظر توسط کتاب‌خانه‌های گرف‌کیوال تایپ‌ها اعتبار سنجی شده‌اند و با خیال راحت می‌تونیم وقت برای منطق اختصاصی برنامه خودمون صرف کنیم.با قدرت و اقتدار کد بزنیدجمع‌بندیتا به اینجا گرف‌کیوال رو معرفی کردیم و برخی از فواید و مشکلاتی رو که حل می‌کنه رو بیان کردیم. در بخش بعد با استفاده از Django و Graphene یه ای‌پی‌آی ساده گرف‌کیوال رو پیاده سازی خواهیم کرد. تِک‌بلاگ سحاب سید مرتضی موسوی Mon, 22 Feb 2021 16:28:57 +0330 https://virgool.io/SahabPardaz/%D8%A8%D8%B1%D9%88%D9%86%D8%AF%D9%87%DB%8Crelease-%D8%AF%D8%B1-%DB%8C%DA%A9-%D8%B3%D8%B1%D9%88%DB%8C%D8%B3-%D8%AC%D9%87%D8%A7%D9%86%DB%8C-ojirgmxld8ex (ویرایش: یک سیستم نمونه در نوشتار دیگری ارائه شده که برخی مفاهیم نوشتار زیر را ملموس‌تر می‌کند.)اگر یک سرویس نرم‌افزاری بالغ و باآبرو دارید یا قراره داشته باشید، فرایند انتشار (release) ناموسی می‌شه. منظور از بالغ، سیستمی‌ست بزرگ‌شده با کلی قابلیت و مولفه و همچنین سرعت (velocity) بالا در توسعه---یعنی تغییرات پیوسته در سیستم و انتشار مکرر نسخه‌ها که همه باید قابل اطمینان باشن---و منظور از باآبرو یعنی هر مشکل کوچکی می‌تونه برابر باشه با ضرر مالی و صد برابر غیرمالی به اعتبار محصول و brand.چند رویه‌ی مربوط به فرایند انتشار که در سرویس‌های ما انجام می‌شه و سودمند بوده، یا انجام نمی‌شه و داریم ضربه‌اش رو می‌خوریم، در این نوشتار خلاصه می‌کنم.انتشار یعنی چی؟ اصلا انتشارِ چه چیزی؟ نسخه‌ی کُد یا داده/dataset یا مدل‌های ML یا قابلیتِ پنهان‌شده پشتِ کلید/flag (که خواهیم دید چیه)؟ فعلا با انتشار کُد/binary جلو بریم و در ادامه به بقیه اشاره می‌کنیم. از لحظه‌ای که نوشتن کُد تموم می‌شه، تا لحظه‌ای که در محیط عملیاتی مستقر بشه، یک فرایند عریض و طویل در میونه که می‌شه خیلی سرانگشتی به دو بخش «تست و یک‌پارچه‌سازیِ پیوسته» (continuous integration یا CI) و «انتشار و استقرار» تقسیمش کرد. خیلی خلاصه:بخش CI یعنی سرِ مخزن کُد، مثلا Git HEAD، همیشه تمیز بمونه. چه طوری؟ ابتدا: داشتن N سطح تست؛ واحد/یکپارچه‌سازی/الف-ب/بار/... (unit/integration/A-B/load/... test). سپس: سیستم CI (مثلا Jenkins) به مخزن کُد (مثلا Git) و سیستم بازبینی کد/code review (مثلا Gerrit) وصل می‌شه، و هر changelist/patch توسعه‌دهندگان رو پیش از اجازه‌ی commit به مخزن، در برابر همه‌ی تست‌های موجود می‌سنجه. جزییات بیشتر، خارج از موضوع این نوشتاره. نتیجه‌ی نهایی: سرِ مخزن کد همیشه تمیزه و آماده‌ی انتشار.انتشار یک binary یعنی برداشتن یک بُرش (cut) از مخزن کد، یعنی معمولا آخرین changelistی که همه‌ی تست‌ها رو پاس کرده که ما اصطلاحا بهش می‌گیم «پلاتینی»/platinum یا طلایی (*)، و ساختن binary و استقرار یا push کردنِ گام به گامِ اون در محیط عملیاتی. این استقرارِ گام به گام، به کمک تست‌های قناری (canary) است - مثل قناری که معدن‌کاران می‌برن تا نشت گاز رو بفهمن. موضوع این نوشتار همینه.(*) نکته‌ی کنکوری: آخرین changelist پلاتینی، طبق چیزی که گفته شد که مخزن همیشه تمیزه، باید بشه همون آخرین changelistی که اجازه‌ی commit گرفته و commit شده دیگه، پس پلاتینی و غیرپلاتینی دیگه چه صیغه‌ایه؟ برخی تست‌ها پیچیده‌تر از اون هستن که بشه روی همه‌ی changelistهای commit شونده اجرا کرد و به ناچار روی هر-چند-تا-یک-بار اجرا می‌شن. مثال: تست‌های نیازمندِ بالا آوردن یک محیط مبسوطِ تست (چندین job و ...)، یا خوروندنِ مقادیر زیادی ورودی به اون چیزِ زیرِ تست، یا اجرا کردن برای حداقل N‌ دقیقه، یا ... مثال: تست‌های نیازمندِ اجرا کردن یک خط لوله (pipeline) زمان‌بر و منبع‌خور.پس محیط staging چی؟ عبارت staging سرریزِ معنایی شده. اگر منظور خارج از محیط عملیاتی باشه، در تقسیم‌بندیِ بالا جزو CI حساب می‌شه و اگر بخشی از محیط عملیاتی و زیرِ بارِ واقعی باشه، بخشی از قناری.بدیهیات: کل سیستم رو نمی‌بریم پایین و دوباره بیاریم بالا. سیستم همیشه بالاست و در مقاطعی ترکیبی از نسخه‌ی جدید و قدیم دارن کنار هم کار می‌کنن (سازگاری رو به عقب / backward compatibility با دو نسخه‌ی قدیمی‌تر، از اصوله). این مساله فقط مربوط به انتشار نیست بلکه برای rollback که یکی از ساز و کارهای اصلی در پاسخ به حادثه‌ست هم ضروری‌ست.انتشار داده/dataset (مثلا lookup tableهایی که توی حافظه‌ی سرورهاست) و مدل‌های ML و بقیه‌ی چیزهای push کردنی چه طور؟ شبیهه، خواهیم دید. انتشار قابلیتِ پشتِ کلید چی بود؟ binary و داده‌ی لازم منتشر شده ولی قابلیتِ مورد نظر ما هنوز غیرفعاله مگر این که یک کلیدی فعال باشه که ما به مرور فعال می‌کنیم مثلا اولش فقط روی ۰/۱٪ درخواست‌ها یا فقط برای ۰/۱٪ کاربران، سپس برای ۱٪ و ...قناری‌گری رو طبقه‌بندی نمی‌کنم و چنین نگاه جامعی اصلا فراتر از بنده‌ست. تنها مثال‌هایی از چند محصول رو ببینیم برای پیشنهاددهی و پیشنهادگیری.۱. محصول CDNاین محصول شامل دریایی از cache serverهاست که درخواست‌های کاربران رو پاسخ می‌دن، و نیز شامل دم و دستگاهی offline/نیمه-online خارج از مسیر بحرانی درخواست کاربر (critical query path) که «داده» آماده می‌کنه برای push کردن به سیستم و استفاده در مسیر بحرانی، مثلا یک lookup table برای نگاشت (mapping) از آدرس IP subnetهای دنیا به این که به کدوم سرورها (PoPها) باید برن.نیمه‌ی اول - سرورهای درگیر با کاربر: binary جدید، که چنان‌که گفته شد همه‌ی تست‌های offline موجود رو از پیش پاس کرده، روی فقط یک یا چند سرور مستقر می‌شه تا برای چند ساعت کار کنه و دَم بکشه و جا بیفته (bake time)، سپس روی یک datacentre کامل مستقر می‌شه و جا می‌افته، سپس روی یک metro کامل---همیشه هم یک datacentre و metro یکسان---و نهایتا استقرارِ جهانی. در هر گام، پس از جا افتادنِ چند ساعته، شاخص(metric)های گوناگونی از سرور بررسی می‌شه تا ببینیم چیزی تغییر نکرده باشه و اگر کرده بررسی بشه، و سپس می‌ریم به گام بعد و باز جا افتادنِ چند ساعته و بررسی و به همین شکل. این تعریفِ کلاسیکِ قناری‌گری در یک سرویسه.این فرایند بسیار مقدماتی و ناکاراست (البته شاید هم دیگه چنین نباشه چون آخرین اطلاع بنده از اون تیم مربوط به ۶ سال پیشه). ایرادها رو با مقایسه با سرویس «نمایش تبلیغات» در پایین خواهیم دید.نیمه‌ی دوم - دم و دستگاهِ تولیدِ داده: این دم و دستگاه نیمه-online، شامل یک stack از jobهاست---یا یک خط لوله (pipeline)---که یک سروی داده‌های ورودی گردآوری کنه و داده‌ی خروجی تولید کنه برای push کردن به سیستم.در یک چینش استاندارد N+2، این stack در واقع در سه stack موازی بالاست و اجرا می‌شه که رهبرگزینی (leader election) می‌کنن به کمک سرویسی معادل ZooKeeper، و یکی از سه تا می‌شه رییس و داده به سیستم push می‌کنه و دوتای دیگه می‌شن علی‌البدل و داده‌های تولیدیشون رو می‌ریزن دور؛ فقط زنده‌ان برای این که اگر رییس مُرد بلافاصله یکی حاضر و آماده جانشین بشه در حالی که همچنان یک علی‌البدل داره (N+1) تا زمانی که اون رییس قبلی برگرده.قناری‌گری چنین سیستمی---یا عموما یک خط لوله‌ی خارج از مسیر بحرانی---ساده‌تر از سرویس‌های درگیر با کاربره: یک stack موازی بالا می‌آریم برای قناری، و داده‌های تولیدیش رو در کنارِ داده‌های تولیدیِ stackهای محیط عملیاتی بررسی می‌کنیم. البته همچنان بدیهی نیست، ولی دیگه پیش‌رَوی گام به گام و کنترل ریسک و کنترل دامنه‌ی انفجار (blast radius) هم لازم نیست. جزییات فراوانی رو حذف کردم ولی امیدوارم مفهوم منتقل شده باشه.۲. محصولِ دستِ کاربرمحصول Nest رو تصور کنید، یا اصلا سیستم عامل Android - یعنی نیاز به push کردن به دستگاهِ دستِ کاربر و نه به سرورهای دستِ خودمون. تست‌های دستگاه، مثلا Nest، کمی متفاوت با تست یک سرویسه و با دخالت انسانیِ بیشتری درگیره، چون مثلا باید روی دستگاه یک دکمه فشار داده بشه بعد روی Mobile App یه کاری بشه بعد سیمِ دستگاه جدا بشه و ... البته این تست‌ها رو تیم‌های مهندسان نرم‌افزارِ ساعتی N دلاری انجام نمی‌دن بلکه تیم‌هایی از کارکنان قراردادیِ سطح پایین‌تر انجام می‌دن. خلاصه سیستم CI که در بالا گفته شد، در این دنیا فرق می‌کنه.برای انتشار، imageی که این تست‌ها رو گذرونده، برای push شدن به دستگاه‌های ملت در دنیا فرایندی کم و بیش ساده و استاندارد طی می‌کنه: push شدن در چند گام مثلا به ۰/۱٪ کاربران و سپس ۱٪ و ۱۰٪ و الی آخر - البته پوشش خوبِ تست قناری (مثلا جغرافیایی) نیازمند اینه که انتخاب این نمونه‌های آماری درصدی، صرفا تصادفی محض نباشه.اما یک گامِ امتیازی پیش از از این pushها، مرحله‌ایست که به نام «چشیدنِ غذای سگ» (dogfood)، یعنی push به دستگاه‌های شرکت که در دست صدها یا هزاران نفر از کارکنان خود شرکته. کارکنان، از هر تیمی با ربط یا بی‌ربط، می‌تونن ثبت نام کنن و دستگاه‌های رایگان برای استفاده‌ی شخصی دریافت کنن به این شرط که دریافت کننده‌ی imageهای dogfood باشه (در نتیجه کمی ناپایدارتر) و هر مشکلی هم دیدن bug گزارش بدن. گاهی پیش از dogood یک مرحله‌ی غیررسمی به نام fishfood هم مصطلحه که شامل قناری کردن روی دستگاه‌هاییه که دستِ اعضای خودِ تیمه - همون «کوزه‌گر از کوزه شکسته آب می‌خوره» که کوزه شکسته یعنی ناپایدارترین حالتِ دستگاه.۳. سرویس نمایش تبلیغاتاین محصول، به طور ساده شامل یک stack (در واقع درخت) از سرویس‌ها و jobهای مختلف است که همدیگر رو فرامی‌خونن. درخواستِ نمایش تبلیغ، از مرورگرِ کاربر به سرِ stack فرستاده می‌شه، می‌ره پایین و پردازش می‌شه و پاسخش برمی‌گرده بالا فرستاده می‌شه به مرورگرِ کاربر - حالت معمولِ هر سرویس آنلاین. این سیستم هم، هم شامل jobهاییست در مسیر بحرانی درخواست کاربر (critical query path) و هم jobهایی بیرون از مسیر بحرانی که اون کنار مشغول تهیه‌ی داده و یادگیریِ مدل و غیره هستن برای push کردن به و استفاده در سیستم.برای انتشار هر یک از jobهای بحرانیِ درختِ بالا، نخست فرایندِ ابتدایی که در مثال CDN گفته شد رو تصور کنید: استقرارِ گام به گام روی {یک سرور، یک datacentre، دنیا} و بررسی شاخص‌ها (metricها) در هر مرحله. ایرادهای این فرایند چیه؟استقرار روی یک سرور، عملا فقط یک «تست دود» (smoke test) است یعنی اگر چیزی به طرز افتضاحی ترکید ببینیم، ولی اطمینان چندانی از ایمن بودن نسخه‌ی جدید نمی‌ده چون فضای نمونه بسیار کوچک است و نویز بالا و معناداریِ آماری تعطیل. یعنی یک شاخصِ تحت نظر (مثلا تعداد کلیک) باید حداقل مثلا ۳۰٪ اُفت کنه تا دیده بشه، چون تا ۲۵٪ اُفت اصلا توی خودِ نویزِ مقایسه گُمه. ۳۰٪ آستانه (threshold) خیلی بزرگ و شُل و وِلی‌ست و مطلوب نیست.استقرار روی یک datacentre هم، هر چند داده‌ی بزرگ‌تر می‌ده، ولی همچنان نویز بالا داره و معناداریِ آماری تعطیل، چون اون datacentre (که داره نسخه‌ی جدید رو اجرا می‌کنه) رو می‌خوایم با چی مقایسه کنیم؟ طبیعتا با یک datacentre نزدیک که داره نسخه‌ی پیش رو اجرا می‌کنه (نه با کل بقیه‌ی دنیا) - که دو گروه آزمایش و کنترل شبیهِ هم داشته باشیم برای مقایسه‌ی مثلا سیب سیب. ولی دو datacentre مجزا، هرچند نزدیک هم، باز مقایسه‌ی سیب و پرتقاله.استقرار روی یک سرور یا یک datacentre، مطلقا پوشش کاملی به ما نمی‌ده چون بسیاری حادثه‌ها فقط در برخی جاها اتفاق می‌افتن - مثلا یک مشکل برای فقط کاربران فلان شهر یا فلان زبان یا فلان سخت‌افزار. یعنی قناری در یک جایی تست شده و به راحتی پاس می‌شه و می‌ره مستقرِ جهانی می‌شه، ولی در جای دیگه می‌ترکه.برای انتشار job الف، ممکنه شاخص‌های سرورهای الف همه سالم باشن ولی پاسخی که سرورهای الف به سرورهای ب می‌دن و ب به پ، باعث مشکل در ب و پ بشن. با قناری‌های گفته شده نمی‌شه چنین اثراتی رو بررسی کرد، چون هر سرور در لایه‌ی الف با N سرور در لایه‌ی ب حرف می‌زنه و برعکس - و همین‌طور در لایه‌ی بین datacentreای. یعنی یک بُرش عمودی «فقط قناری» نداریم. چرا نداریم؟ چرا به سادگی یک stack/درخت موازی نمی‌آریم بالا برای قناری؟ چون یکی دوتا که نیست. ده‌ها job داریم و صدها data و model و قابلیت که هر یک باید مدام قناری بشن و انتشار. stack قناری رو به کدوم بدیم؟ ساده نیست.راه‌حل‌های که ما استفاده می‌کنیم و سودمند بوده، یا استفاده نمی‌کنیم و دوست داریم کاش می‌شد، اینه:قناری تک‌سروری در چندین datacentre به طور چرخشی و غیرثابت، طوری که هر بار پوشش جغرافیایی خوبی داشته باشیم.قناری half datacentre، یعنی نپریدن از «یک سرور» به «یک datacentre» بلکه استقرار روی نصف سرورهای یک datacentre و در نتیجه مقایسه‌ی نصف نصف، یعنی واقعا مقایسه‌ی سیب سیب و نویز بسیار پایین. یعنی اگر یک شاخص مثلا ۱۰٪ اُفت کنه می‌تونیم شکارش کنیم. چرا تَنگ کردن این بازه مهمه؟ چون ۱۰٪ اُفت در شاخص الف (مثلا تعداد کلیک) اولا به خودی خود بَده و تمام، ولی دوما معمولا همگن نیست بلکه ناشی‌ست از اُفت ۱۰۰٪ی برای بُرشی از سیستم (که در شاخص تجمیع شده ۱۰٪ دیده می‌شه)، مثلا فقط کاربرانِ پشتِ فلان سیستم عامل یا کاربرانِ فلان منطقه یا فلان بخش محصول. بخشی از راه حل برای شکار چنین مشکلاتی، بُعد دادن به شاخص‌هاست که در نوشتار دیگری آمده، و بخش دیگر، میسّر کردنِ تنگ و تنگ‌تر شدن آستانه (threshold)ها.ساز و کاری برای برچسب زدن به logهای درخواست‌ها، به طوری که در پایان معلوم بشه پاسخ به یک درخواست، از کدوم نسخه‌ی job الف و کدوم نسخه‌ی ب و کدوم نسخه‌ی داده‌ی پ و کدوم نسخه‌ی مدل ت رد شده و همچنین کدوم قابلیت‌های پشتِ کلیدِ ث و ج روش فعال بودن و نبودن، تا علی‌رغم قاطی بودن قناری و غیرقناری، با تجمیعِ logهای برچسب خورده در پایان بتونیم اثر الف و ب و... و ج رو در کل سیستم ببینیم.ساز و کاری برای کنترل دامنه‌ی انفجار. اصطلاح «درخواست مرگ» (query of death) رو شاید شنیدید: درخواستی که مثل هر درخواست دیگری مثلا روی برگ (leaf)های یک زیرسیستم بازیابی اطلاعات پخش می‌شه ولی یک bug رو در اون‌ها فعال می‌کنه، یعنی یک درخواست به تنهایی کل سیستم رو می‌آره پایین. بعد هم retry می‌شه و ... (نتیجه‌ی فرعی: حتما برای سیستمتون به ساز و کاری برای query of-of-death filter فکر کنید). به همین صورت، یک تک‌سرور قناری در لایه‌ی الف می‌تونه درخواست/پاسخ خراب به لایه‌ی بعدی بده و کل سرویس ب یا پ رو بیاره پایین. در لایه‌ی اول سرورهای قناری از غیرقناری جداست، ولی از لایه‌ی بعدی به پایین، این جداسازی یا مستلزم دست‌کاریِ هوشمند در لایه‌ی RPC و الگوریتم load balancing است که سخته و فراموشش کن، یا مستلزم طراحی و بده‌بستان (tradeoff) برای بالا آوردن stack موازی ولی نه برای قناریِ هر چیزی.انتشار داده و مدل‌های جدید (شامل انتشار jobهای غیربحرانی که اون‌ها رو تولید می‌کنن)، مشکل‌ها و راه‌حل‌هایی مشابه قناری jobهای بحرانی که در بالا گفته شد داره: داده‌ی جدید به زیرمجموعه‌ای از سرورها داده می‌شه و شاخص‌ها سنجیده می‌شه، و همین‌طور مشکل‌ها راه‌حل‌های قناری‌گری عمودی.۴. جمع‌بندیاشتباه نشه، اون‌چه گفته شد برای انتشار به محیط عملیاتی، ساز و کار اصلی برای «تست محصول» نیست، بلکه ساز و کار اصلی برای «استقرار» محصولِ پیش‌تر-کاملا-تست-شده است.بیشترِ تمرکز این نوشتار بر انتشار در یک سرویس بود، و به انتشارِ محصول دست کاربر تنها اشاره‌ی کوتاهی شد. این به دلیل ساده بودن یکی و پیچیده بودن دیگری نیست بلکه تنها به دلیل درگیری بیشتر و کمتر بنده با تیم‌های این شکلی و اون شکلی بوده و معنی دیگری نداره.بسیاری از پیچیدگی‌هایی که بحث شد، ربطی به جهانی بودن سرویس نداره بلکه در سرویسی مستقر در یک datacentre تنها هم وجود خواهد داشت، و بیشتر به پیچیدگی خودِ سرویس مربوط می‌شه.مداخله‌ی انسانی در فرایندهایی که گفته شد، تنها در خط دوم دفاعی است یعنی مثلا مرور نتیجه‌ی تست‌ها/گام‌هایی که سبز نشدن. اگر بشه این حجم رو به نزدیک صفر رسوند، می‌شه رسیدن به کیمیای «push on green» - در این باره این مقاله‌ی خواندنی از گوگل رو ببینید. تِک‌بلاگ سحاب Kian Sat, 26 Dec 2020 20:56:27 +0330 https://virgool.io/SahabPardaz/%D8%AF%D8%A7%D8%B3%D8%AA%D8%A7%D9%86-%DB%8C%DA%A9-%D8%B3%D9%82%D9%88%D8%B7-%D9%BE%DB%8C%D8%B4%D8%A8%DB%8C%D9%86%DB%8C-%D8%B1%DB%8C%D8%B2%D8%B4-%D9%85%D8%B4%D8%AA%D8%B1%DB%8C%D8%A7%D9%86-qbz4nc2xbsvj ریزش چیزهایی که خود، آن ها را به دست آورده ایم بسیار دردناک است!!همیشه مشتری به عنوان یه موجودیت ارزشمند برای کسب‌و‌کارهای مختلف حساب می‌شده. کسی یا سازمانی که با هزینه به عنوان مشتری به‌دست میومده و قرار بوده برای کسب‌و‌کار منبعی از درآمد باشه. حالا قطعا از‌دست دادن یه همچین موجودی! میتونه خیلی برای هر کسب‌و‌کاری دردناک باشه به خاطر همین اگه بتونیم زودتر جلوی این داستان ناگوار رو بگیریم قطعا به کسب‌و‌کار کمک کردیم. از اینجاست که پیش‌بینی این سقوط، مهم و تاثیرگذار می‌شه.توی این پست قصد داریم که یه تحلیل تمیز از ریزش مشتریان ارایه بدیم و تجربه‌ای که خودمون توی سکان به‌دست آوردیم رو با یه دیتای عمومی که اتفاقا توی آوردگاه کگل هم میشه پیداش کرد، توضیح بدیم. این دادگان شامل اطلاعات کمپین‌ها و تخفیف‌ها و تراکنش‌ها ست. اما ما فقط از اطلاعات تراکنش‌ها استفاده می‌کنیم چرا که خیلی مواقع فقط اطلاعات تراکنش‌ها در دسترس هستند گرچه نوت‌بوک‌های دیگه‌ای که روی این دادگان منتشر شدن از اطلاعات دیگه‌ای هم استفاده کردن. کد کامل این تحلیل رو می‌تونید اینجا ببینید.خواندن دادگان و بررسی‌های اولیهخواندن دادگان تراکنش‌هادر این دادگان چند ویژگی نقش کلیدی بازی می‌کنن. ویژگی household_key در واقع شناسه مشتریان کسب‌و‌کاره. همچنین ویژگی BASKET_ID شناسه سفارش مشتریانه. هر سفارش میتونه شامل چندین کالا باشه که در این صورت ممکنه یک شناسه سفارش در چندین سطر تکرار بشه تا کالا‌های مختلف یک سفارش اعلام بشن. ویژگی‌های QUANTITY و SALES_VALUE نیز به ترتیب، تعداد کالا در آن سطر سفارش و حجم خرید از آن کالا در سطر سفارش رو مشخص می‌کنه.قبل از مدل‌سازی لازمه تا بررسی‌های آماری روی دادگان انجام بدیم. برای این کار خوبه که روی ویژگی‌های کلیدی، مقادیر بیشینه و کمینه و توزیع متغیر‌ها رو بدونیم. همین طور بفهمیم که کجاها مقادیر غیر معقول وجود داره یا مثلا چه سطر‌هایی مقادیر None دارن. یکی از مقادیر مرسوم در دیتای فروش کسب‌و‌کارها، مقادیر منفی برای QUANTITY یا SALES_VALUE هست که نشون‌دهنده سفارش‌های برگشتی هست. برخی جاها هم ممکنه برای این نوع سفارش‌ها مقادیر صفر رو در نظر بگیرن. تو این دادگان همین اتفاق افتاده. برای تحلیل لازمه که این سفارش‌ها حذف بشن تا توی سفارش‌های هر مشتری لحاظ نشن. ( البته ممکنه شما ایده بزنین و از دل همین سفارش‌ها هم بخواین ویژگی در بیارین ولی چیزی که مهمه اینه که نباید با این سفارش‌ها مثل سفارش‌های عادی برخورد بشه و ما هم ساده‌ترین راه رو انتخاب کردیم ینی حذف ! ) نمودار هیستوگرام مقادیر QUANTITYهمچنین مقادیر None رو هم بر روی دادگان بررسی میکنیم که اگه وجود داشتن یه فکری به حالشون بکنیم. برای ویژگی‌های کلیدی household_key و BASKET_ID و SALES_VALUE هیچ مقدار None ای وجود نداره.بررسی مشتریاندر این مرحله میخوایم از داده تراکنش‌ها به داده مشتریان برسیم. برای همین بر اساس household_key باید group_by کنیم و ویژگی‌های مختلفی از جمله تعداد خرید هر مشتری یا frequency و مجموع خرید هر مشتری یا monetary رو استخراج کنیم. تابع convert_transaction_to_customers ویژگی‌های مختلف رو از تراکنش‌ها استخراج می‌کنه. لازمه به این نکته توجه کنیم که برخی مشتریان به صورت خیلی کم از کسب‌و‌کار خرید انجام داده‌اند و به نوعی مشتریان غیرعادی تلقی می‌شوند. به همین دلیل توزیع frequency رو بر روی مشتریان بررسی می‌کنیم تا یه سطح آستانه مشخص برای مشتریان پیدا کنیم و مشتریانی که کمتر از اون مقدار دفعات خرید داشتن رو حذف کنیم.فضای ویژگی جدید برای مشتریانفضای ویژگی جدیدی که برای مشتریان بدست اومده از روی اطلاعاتی هست که از متخصصان این دامنه گرفته شده. این ویژگی‌ها میتونن تفسیر نسبتا خوبی از رفتار خرید هر مشتری ارایه بدن. مثلا مقدار recency فاصله زمانی آخرین خرید هر مشتری از تاریخ روز هست. یا مثلا product_diversity برابر تعداد انواع کالایی هست که هر مشتری خریده. پارامتر periodicity هم فاصله زمانی بین هر خرید مشتری هست که آماره‌های مختلف مانند میانگین و انحراف از معیار و ... بر روی اون حساب شده. مقدار AOV هم برابر میانگین ارزش خرید هر مشتری هست. توزیع ویژگی‌های بالا رو میتونین ببینین.نمودار هیستوگرام توزیع فضای ویژگی بر روی مشتریانتوزیع frequency برای مشتریانبا بررسی توزیع frequency، مشتریانی که کمتر از ۱۰ بار خرید انجام دادن رو حذف می‌کنیم. این مشتریان به نوعی داده پرت محسوب می‌شن و می‌تونن تعمیم‌پذیری مدل احتمالاتی رو خراب کنن.یه پارامتری که خیلی می‌تونه توی تحلیل ریزش موثر باشه مقدار D/F یه کسب‌و‌کار هست. مقدار D/F همان میزان duration هر مشتری تقسیم بر مقدار frequency همون مشتریه و میانگین مقادیر D/F یه پارامتر مهم هست که رفتار کلی کسب‌و‌کار رو براساس دفعات خرید تعیین می‌کنه. پارامتر duration هم به میزان حضور یه مشتری توی کسب‌و‌کار برمی‌گرده ینی بازه بین اولین و آخرین خرید هر مشتری. با پارامتر D/F جلو‌تر کار داریم! اما علی الحساب بدونین که این مقدار برای این دادگان حدود ۱۱.۱۹ روز هست. به این معنی که توی این کسب‌و‌کار امید میره که هر مشتری حدودا هر ۱۱ روز یک‌بار خرید انجام بده. البته توی محاسبه این KPI هم لازمه که اول مشتریان تک خرید حذف بشن چرا که مقدار duration برای این مشتریان برابر صفر هست و این مقدار میتونه ما رو گمراه کنه. تعریف ریزش مشتریانقبل از ورود رسمی به مساله باید که ریزش یک مشتری رو تعریف کنیم. برای ریزش مشتریان تعریف رسمی وجود نداره ولی با توجه به اطلاعاتی که از متخصصان این دامنه گرفتیم معمولا مشتری که بیش از مقدار دو برابر میانگین D/F توی کسب‌و‌کار خریدی انجام نده به عنوان یه مشتری ریزش کرده شناسایی می‌شه. اینجاست که اهمیت این پارامتر مشخص می‌شه. البته ما روی دادگان های مختلف با D/F های متفاوت هم تست کردیم و دیدیم که یک مدل بر روی کسب‌و‌کار‌هایی با D/F های نزدیک بهم تا حد بسیار زیادی نتایج یکسان ارایه می‌کنه و این نشون میده که توی تحلیل ریزش مشتریان این پارامتر میتونه نقش کلیدی ایفا کنه. با توجه به تعریف بالا لازمه که از روی دیتای تراکنش‌های کسب‌و‌کار، الگوهای رفتاری خرید مشتریان رو به‌دست بیاریم و بعد این‌ها رو براساس تعریف ریزش مشتری، برچسب بزنیم تا برای فاز مدل‌سازی آماده بشیم. برای این کار یک پنجره لغزان M روزه رو با گام S روزه بر روی داده تراکنش‌ها حرکت می‌دیم. باید تابعی داشته باشیم تا رفتار M روزه هر مشتری رو به یه فضای ویژگی جدید ببره که بتونه رفتار اون مشتری رو توصیف کنه و بعد هم چنانچه توی N روز آینده خریدی انجام نداده بود، به اون الگوی رفتاری برچسب ۱ ( به‌معنای ریزش کرده) و در غیر این صورت برچسب ۰ بزنه. این تبدیل رو تابع transform_data انجام می‌ده. شیوه کار به این صورته که رفتار خرید M روزه مشتری شامل یه سری ویژگی‌های تجمیعی از قبیل تعداد دفعات خرید در اون بازه، حجم خرید در اون بازه و یا فاصله آخرین خرید مشتری تا آخرین روز بازه خواهد بود.( تعداد این ویژگی‌های تجمیعی ۱۲ تاست ). همچنین به ازای هر روز در این بازه، چنانچه مشتری در اون روز خریدی انجام داده باشه حجم خرید در اون روز و تعداد انواع کالا و تعداد کالایی که خریده رو در ۳ بعد اضافه می‌کنه و در غیر این صورت مقدار هر یک از این سه بعد رو برابر با صفر میذاره. با توجه به این توضیحات رفتار M روزه مشتری با یه بردار 12+3*M بعدی توصیف میشه و اگر هم در بازه N روزه آتی خریدی نداشت مقدار label برای اون الگوی رفتاری مشتری برابر ۱ و در غیر این صورت برابر صفر خواهد بود.مقدار N با توجه به تعاریف بالا برابر با حدود دو برابر شاخص D/F ینی ۲۰ روز خواهد بود و مقدار M هم باید با Hyper-Parameter-Setting به دست بیاد که با آزمایشاتی که ما انجام دادیم این مقدار برابر با ۴۰ روز هست. همچنین پارامتر S هم با توجه به نرخ انجام تراکنش توی اون کسب‌و‌کار انجام میشه. در این دادگان هر ۱.۱ روز یه تراکنش انجام شده به همین دلیل مقدار S رو برابر با ۲ روز گذاشتیم. با استفاده از تحلیل PCA می‌تونیم این فضای ۱۳۲ بعدی را در سه بعد ببینیم.نمودار scatter فضای ۱۳۲ بعدی رفتار مشتریان. نقاط قرمز، مشتریان ریزش کرده هستند. نسبت دیتای ریزش کرده به ریزش نکرده حدود ۱ به ۶ است. با توجه به اطلاعات دامنه اگه کسب‌و‌کاری سالم و سرپا باشه باید نسبت مشتریان ریزش کرده به نکرده در اون کمتر از ۱ به ۵ باشه. این نشون میده تعریف ما از ریزش با واقعیت‌های میدانی هم سازگاره.با توجه به توضیحات بالا مساله ریزش برای این دادگان به این صورت تعریف میشه که رفتار ۴۰ روزه هر مشتری رو به عنوان ورودی می‌گیریم و پیش‌بینی می‌کنیم که آیا در ۲۰ روز آینده خریدی انجام خواهد داد یا خیر. قبل از هر چیز باید دیتای آموزش رو از دیتای تست جدا کنیم. برای اینکه مدل ما تعمیم‌پذیری بیشتری داشته باشه باید این دیتاها رو با توجه به فاز زمانی از هم جدا کنیم. مثلا دیتای تراکنش a روز اول رو برای آموزش و b روز بعدی رو برای تست در نظر بگیریم. به دلیل اینکه پارامتر های مساله رو تعیین کردیم پس دیتای ۶۰ روز آخر رو برای تست و مابقی دیتا رو برای آموزش درنظر می‌گیریم.دیتای تستدیتای آموزشمدل سازیبا توجه به اینکه نسبت داده‌های ریزش کرده به ریزش نکرده حدود ۱ به ۶ هست، داده موجود از نوع imbalanced هست. فرآیند یادگیری در این مدل‌ها می‌تونه تا حد زیادی سخت و دشوار باشه. این هم به این دلیله که شبکه عصبی ممکنه به سمت کلاسی که داده بیشتری ازش موجود هست غش کنه!! و همزمان اگه از کلاس کمیاب‌تر دیتای کافی وجود نداشته باشه حتی توزیع داده کمیاب‌تر رو هم نمی‌تونه یاد بگیره. متدهای زیادی وجود داره که توی مساله دسته‌بندی با داده های imbalanced بتونیم ازشون استفاده کنیم و مدل رو بهتر آموزش بدیم. با توجه به اینکه از کلاس کمیاب، ینی الگوهای رفتاری ریزش کرده، نسبتا تعداد داده‌های مناسبی وجود داره ( حدود ۱۰۰ هزار الگوی ریزش داریم) می‌تونیم از تکنیک under-sampling استفاده کنیم به این صورت که از دسته‌ای که دیتای بیشتری از اون موجوده به صورت تصادفی حدود ۱۰۰ هزار دیتا برمیداریم تا تعداد دو کلاس با هم بالانس بشه. اما چون دوست داریم از دیتاهای خوبی که از کلاس الگوی‌های ریزش نکرده داریم هم به خوبی استفاده کنیم ابتدا مدل رو روی کل داده‌ها آموزش می‌دیم و بعد با Fine-Tuning به صورت بالانس شده شبکه رو آموزش می‌دیم. مد fine-tuning ای که استفاده می‌کنیم هم به صورت ساده و INIT هست ینی با همان وزن‌هایی که شبکه در مد اول آموزش دیده، آموزش رو ادامه می‌دیم. معماری شبکه و تعداد پارامترهای آن در زیر اومده.معماری شبکه برای آموزش مساله ریزش مشتریان. طبق یه قانون سرانگشتی تعداد داده‌های لازم برای جلوگیری از آورفیت شدن شبکه حدود ۱۰ برابر تعداد پارامتر هاست.در این شبکه از لایه‌های batch_normalization استفاده شده تا استانداردسازی داده‌ها در سطح معماری شبکه انجام بشه. همچنین برای جلوگیری از آورفیت شدن شبکه از dropout با نرخ ۰.۵ استفاده کردیم. از طرفی از تکنیک early_stopping نیز استفاده کردیم تا هر چه بیشتر از داده‌های آموزشی استفاده کنیم و از آورفیتینگ دورتر بشیم. این شبکه را یکبار با کل داده‌ها و بعد هم با داده‌های بالانس شده آموزش دادیم. نمودار داده‌های بالانس شده به صورت زیر هست.نمودار scatter داده‌های بالانس شده. نقاط قرمز مربوط به دیتای ریزش می‌باشد.آموزش شبکه و ایجاد شبکه عصبی توسط ابزار Keras انجام شده که API بسیار ساده‌ای برای طراحی و آموزش شبکه‌های عصبی عمیق داره. همچنین معیار ارزیابی رو معیار AUC یا Area Under Curve انتخاب کردیم. علت هم اینه که هم مساله با دیتای Imbalanced رو به رو هست و هم اینکه لایه آخری که برای تصمیم‌گیری کلاس داده استفاده شده تابع Sigmoid هست که یه عدد احتمالاتی بین ۰ تا ۱ برمیگردونه و خیلی مهمه که حد آستانه رو برای این تابع چه عددی در نظر بگیریم تا مشخص بشه از چه احتمالی بیشتر رو باید به عنوان یک الگوی ریزش در نظر گرفت. با نمودار ROC میتونیم این مقدار رو به راحتی تنظیم کنیم البته باید توجه کنیم که در این حالت باید حتما دیتای validation جداگانه ای هم داشته باشیم تا ازش برای تنظیم این پارامتر استفاده بشه. تابع loss هم با توجه به ذات مساله تابع BinaryCrossEntropy انتخاب شده. در ادامه نحوه تغییر معیار ارزیابی و تابع loss در طول فرآیند آموزش قابل مشاهده ست.تابع loss برای آموزش شبکه. علت کمتر بودن loss شبکه در حالت validation این هست که لایه dropout در این فاز غیر فعال هست.نمودار تغییر معیار AUC در طول فرآیند آموزش. علت اینکه معیار ارزیابی در حالت validation بهتره به خاطر غیر فعال بودن لایه Dropout در حالت validation هست.تحلیل خطابا اقدامات انجام شده نتایج به دست اومده رو می‌تونیم روی ماتریس زیر ببینیم:ماتریس درهم‌ریختگیبا توجه به ماتریس بالا میزان recall حدود ۷۰ درصده. ینی از بین تمام الگو‌های ریزش تونستیم ۷۰ درصدشون رو تشخیص بدیم. از طرفی مقدار precision نیز ۴۰ درصد هست. ینی از بین الگو‌هایی که به‌عنوان ریزش پیش‌بینی کردیم حدود ۴۰ درصدشون واقعا ریزش کرده بودن. اما علت اینکه مقدار precision پایین هست چیه و آیا بهتر می‌تونه بشه یا نه؟ این سوال مهمی هست که با تحلیل خطاهای موجود می‌تونیم بفهمیم وضعیت چه طوره!نمودار ROC برای پیش‌بینی ریزش. با تنطیم مقدار حد آستانه تشخیص به اندازه 0.5481 می‌تونیم به recall حدود ۷۰ درصد و false positive rate حدود ۲۲ درصد رسید.با بررسی خطاهای false positive ینی مشتریانی که ریزشی نبودن ولی ما اونا رو ریزشی پیش‌بینی کردیم متوجه می‌شیم که اغلب اونا ( ینی حدود ۷۰ درصد) کسانی هستن که فقط ۱ خرید داشتن. پس ینی خیلی به ریزش نزدیک بودن در حالی که مشتریانی که ریزشی نبودن و ما هم اونا رو درست تشخیص دادیم عموما ۲ یا ۳ یا ۴ خرید داشتن. همچنین میتونیم ۴ دسته ماتریس درهم‌ریختگی رو از منظر آماره‌های D/F و یا recency بررسی کنیم که ببینیم ایا بر روی این ویژگی‌ها هم می‌تونیم جداسازی داشته باشیم یا نه. نمودار joint توزیع D/F و recency برای داده‌هایی که به عنوان ریزش پیش‌بینی شده اندنمودار joint برای D/F و recency برای داده‌هایی که به عنوان عدم ریزش پیش‌بینی شده‌انداز روی نمودار های بالا می‌تونیم نتیجه بگیریم که با گذاشتن یه دسته‌بند خطی بر روی خروجی شبکه عصبی می‌شه نتایج پیش‌بینی رو بهتر کرد. کاری که در آینده به عنوان بهبود میشه روی مدل فعلی پیاده کرد. البته همین دو ویژگی رو به عنوان ورودی در شبکه عصبی داشتیم ولی احتمالا به خاطر کمبود داده، مدل نتونسته اهمیت بیشتری رو به این دو ویژگی بده. این شهود میتونه ما رو به معماری‌های بهتری هم رهنمون کنه! مثلا ممکنه یه شبکه CNN بتونه اهمیت این ویژگی‌ها رو استخراج کنه.اما سوال اصلی اینه که مقدار precision تا کجا می‌تونه بهتر بشه؟ برای جواب دادن به این سوال باید بدونیم از منظر مصالحه bias-variance میزان unavoidable-bias چقدر هست. این میزان خطا در واقع مشخص می‌کنه که حتی یه دسته‌بند بهینه تا چه حد میتونه به دقت خوبی برسه. مثلا تصور کنین که دو تا دیتا در یک فضا کاملا روی هم افتاده باشن و یکی‌شون مربوط به دسته اول و دیگری مربوط به دسته دوم باشن. در این حالت هیچ مدلی نمیتونه تفاوت این دو دیتا رو بفهمه. حالا اگه این دو دیتا خیلی به هم نزدیک باشن شانس پیدا شدن کرنلی که بتونه این دیتا ها رو توی فضای دیگه ببره و این دیتاها از هم کامل دور باشن باز هم پایین میاد. به عبارت دیگه شبکه عصبی ( که لایه‌های خودش می‌تونه به عنوان کرنل فانکشن در نظر گرفته بشه ) با داده‌های ناکافی، به احتمال بسیار بالا نمیتونه اون کرنل رو پیدا کنه. حالا ما می‌خوایم یه تحلیل احتمالا تقریبا درست ارایه بدیم که میزان خطا در precision از چه حدی نمیتونه پایین‌تر باشه. برای این کار ابتدا از هر دو دسته ریزش کرده و ریزش نکرده ۲۵۰۰۰ داده رو به صورت تصادفی بر میداریم. بعد فاصله دو به دوی هر یک از دیتاهای دسته اول رو با دسته دوم محاسبه می‌کنیم. حالا باید ببینیم چند تا داده ریزش نکرده وجود داره که در همسایگی اپسیلون اون حداقل یه داده ریزش کرده هست. در همسایگی کمتر از فاصله ۰.۰۷ حدود ۳۰ درصد از داده‌های ریزش کرده حداقل یک داده ریزش نکرده وجود داره و در همسایگی حدود ۶ درصد از داده‌های ریزش نکرده حداقل یه داده ریزش کرده وجود دارهبا توجه به تصویر بالا و اینکه مدل ما به recall حدود ۷۰ درصد رسیده پس می‌تونیم فرض کنیم که فاصله‌های بیشتر از ۰.۰۷ در مدل ما تشخیص داده شده اما در این حالت حدود ۶ درصد داده‌های ریزش نکرده در همسایگیشون به فاصله کمتر از ۰.۰۷ یه داده ریزش کرده هست. پس در حالت اپتیمال مقدار FPR یا false positive rate میتونه حدود ۶ درصد باشه. با توجه به نسبت داده‌های ریزش کرده و ریزش نکرده ( که حدود یک به شش هست) مقدار precision در حالت اپتیمال حدود ۶۵ درصد خواهد بود. پس دسته‌بند بهینه در بهترین حالت می‌تونه به precision حدود ۶۵ درصد برسه. این به خاطر درهمرفتگی دیتاهای موجود با توجه به فضای ویژگی هست که تشکیل دادیم.جمع‌بندیدر تحلیل بالا ابتدا دادگان رو بررسی کردیم و بعد یه تعریف از ریزش ارایه دادیم. بعدش هم سعی کردیم از روی دیتای تراکنش‌ها الگوهای رفتاری خرید مشتریان رو در بیاریم. کیفیت مدل ارایه شده عالی نبود اما با توجه به تحلیل خطا قابل قبول بود. برای ارزیابی مدل معیار AUC رو معرفی کردیم که باعث میشه با تغییر حدآستانه تابع خروجی sigmoid بتونیم یه مصالحه‌ای بین مقدار recall و false positive rate به‌دست بیاریم. نشون دادیم که توی فضای ویژگی که ترسیم کردیم درهمرفتگی زیادی وجود داره که مقدار unavoidable bias رو بررسی کردیم. یه نکته‌ای که لازمه بهش اشاره بشه اینه که ما از روی داده تراکنش‌ها به فضای ویژگی جدید رسیدیم و این به خاطر محدودیت مدل بود که نمی‌تونه وابستگی‌های زمانی رو به خاطر بسپره. به همین دلیل ما مجبور بودیم فاز مهندسی ویژگی داشته باشیم و ویژگی‌هایی که در بالا توضیح دادیم رو از روی داده به دست بیاریم. همون‌طور که دیدیم فضای ویژگی‌ای که ترسیم کردیم درهمرفتگی زیادی داشت که موجب می‌شد unavoidable bias افزایش پیدا کنه. یه فاز بهبود می‌تونه این باشه ، به جای استفاده از شبکه عصبی feed forward از شبکه LSTM استفاده کنیم و داده‌های تراکنش رو به صورت مستقیم به شبکه بدیم و خود شبکه بهترین فضای ویژگی رو پیدا می‌کرد. البته این روش نیاز به داده‌های بیشتری نسبت به روش فعلی داره ولی می‌تونه تست بشه. مورد دیگه‌ای که باز به عنوان بهبود می‌تونستیم استفاده کنیم این بود که داده‌های مشتریان رو قبل از انجام تحلیل خوشه‌بندی می‌کردیم و برای هر خوشه یه مدل جداگونه ترین می‌کردیم چرا که نحوه ریزش توی خوشه‌های متفاوت مشتریان می‌تونه متفاوت باشه و در تحلیل بالا یه فرض ساده‌سازی ضمنی گرفته شده که مشتریان خوشه‌های مختلف با توزیع یکسان دچار ریزش می‌شن. انشاالله در آینده‌ای نه چندان دور به سراغ این ایده‌ها خواهیم رفت....منابعHands-On Machine Learning with Scikit-Learn, Keras, and TensorFlowPrinciple Component AnalysisDropout: A Simple Way to Prevent Neural Networks from OverfittingBatch Normalization: Accelerating Deep Network Training by Reducing Internal Covariate ShiftReceiver operating characteristic (ROC)Understanding the Bias-Variance Tradeoff تِک‌بلاگ سحاب محمدمهدی آقاجانی Wed, 23 Dec 2020 16:30:17 +0330 https://virgool.io/SahabPardaz/accelerate-ublssivylh5v مقدمه«کد بدون تست نداریم.»«هیچ کدی بدون بازبینی (review) داخل نمی‌رود.»«همه‌ی مراحل استقرار (deployment) خودکارسازی شده است.»«ما مجهز به CI/CD هستیم.»«کارهای بزرگ را به کارهای کوچک‌تر شکسته و کارهای موازی را محدود می‌کنیم.»«همواره از مشتری بازخورد دریافت می‌کنیم.»«در سازمان ما، افراد به داشتن ارتباط مستقیم با تیم‌ها و بخش‌های دیگر سازمان و حتی مدیران تشویق می‌شوند.»احتمالاً تعداد زیادی از این گزاره‌ها به گوش شما هم خورده باشد. شاید حتی خود شما هم چندتایی را استفاده کرده و به آن باور داشته باشید. شاید مطالب زیادی در مورد هر یک خوانده باشید که یک یا چند مورد را تایید یا رد کرده باشند. شاید در سازمان شما هم طرفداران و مخالفانی برای هر یک از گزاره‌ها وجود داشته باشد. اما در دنیای واقعی کدام‌یک درست و کدام‌یک اشتباه است؟این خلأ، چیزی است که کتاب Accelerate تلاش می‌کند آن را پر کند. نویسندگان با مطالعه به روش علمی در یک جامعه‌ی آماری گسترده، عوامل موثر بر کارایی را معرفی و اندازه‌گیری می‌کنند. در مقدمه‌ی کتاب می‌خوانیم:این پژوهش، نیازی را که در حال حاضر در بازار، خدمات‌دهی نمی‌شود، برطرف می‌کند. هدف ما این است که با استفاده از روش‌های دقیق علمی —که پیش از این عمدتاً در محیط‌های پژوهشی استفاده‌ می‌شدند— و دسترس‌پذیر کردن آن برای صنعت، کیفیت توسعه و تحویل نرم‌افزار را بهبود بخشیم. با شناسایی و درک توانایی‌هایی که در عمل به شکلی معنادار کارایی را بهبود می‌دهند —چیزی بیش از فقط داستان‌گویی و فراتر از تجربه‌های یک یا چند تیم— می‌توانیم به بهبود صنعت کمک کنیم.خوراک کتاب، سلسله پژوهش‌هایی است که از سال ۲۰۱۴ با عنوان State of DevOps Report منتشر می‌شود. نویسندگان کتاب در واقع پژوهش‌گرانی هستند که آن را پیش می‌برند: Nicole Forsgren, Jez Humble و Gene Kim. در دنیای مهندسی نرم‌افزار شاید هامبل از سایرین شناخته شده‌تر باشد. او نویسنده‌ی کتاب تحویل مستمر (Continuous Delivery) است.از جمله نکات شگفت‌آور این است که به مواردی بر می‌خورید که بر خلاف انتظار، از جنبه‌ی آماری اندازه‌گیری می‌شوند؛ مثل اندازه‌گیری فرهنگ سازمانی و تأثیر آن روی توسعه و تحویل نرم‌افزار. علاوه بر این، بر پایه‌ی روش علمی، پس از اندازه‌گیری، پیش‌بینی صورت گرفته و درستی پیش‌بینی مورد بررسی قرار می‌گیرد.با این مقدمه، سراغ خود کتاب می‌رویم. کتاب در سه بخش تألیف شده است. من مطالب کتاب را به طور کامل پوشش نداده و به ذکر نکات برجسته بسنده می‌کنم.چطور کارایی را اندازه‌گیری کنیم؟متدولوژی‌ها و چهارچوب‌های کاری متعددی وجود دارند که تلاش می‌کنند روش توسعه‌ی محصولات و خدمات را بهبود دهند. هر یک با ارائه‌ی یک تعریف از «خوب» و اندازه‌گیری کمیت مربوط به آن، مسیر بهبود را به ما نشان می‌دهند. کاستی‌هایی که روش‌های پیشین داشته‌اند، معمولاً مربوط به تعریف اشتباه از «خوب» است. برای مثال، تعداد خط کد، سرعت (velocity) یا بهره‌گیری (utilization) را به عنوان شاخص‌های کارایی در نظر بگیرید؛ آیا تعداد خط بیشتر نشان‌دهنده‌ی کارایی بیشتر یک تیم یا توسعه‌دهنده است؟ تعداد خط کم‌تر چطور؟ عمدتاً ما ترجیح می‌دهیم به جای یک برنامه‌ی هزار خطی با یک برنامه‌ی ده‌خطی دست و پنجه نرم کنیم. حتی دوست داریم با هیچ کدی مواجه نباشیم و کدهای اضافی را پاک می‌کنیم. از سوی دیگر، گاهی یک قطعه کد ده خطی را که واضح است و به راحتی خوانده می‌شود، نسبت به نسخه‌ی فشرده‌شده‌ی سه خطی و جادویی آن که نیاز به رمزگشایی دارد، ترجیح می‌دهیم. بنابراین اندازه‌گیری تعداد خط کد معیار ایده‌آلی نیست.اندازه‌گیری سرعت چطور؟ در فرهنگ اصطلاحات چابک (Agile)، مسائل به تعدادی داستان (story) شکسته شده و به داستان‌ها عددی به عنوان امتیاز (point) نسبت داده می‌شود که برآوردی از میزان نیرویی است که صرف آن کار می‌شود. تعداد امتیازهایی که در هر دوره (iteration) توسط تیم به مشتری تحویل داده می‌شود، قابل اندازه‌گیری است و به آن سرعت تیم گفته می‌شود. هدف طراحی سرعت، ارائه‌ی ابزاری برای برنامه‌ریزی ظرفیت است. یعنی پیش‌بینی زمان کامل‌ شدن کارهایی که برنامه‌ریزی و برآورد شده‌اند. سرعت، یک کمیت نسبی و وابسته به تیم است. به همین دلیل نمی‌توان از آن به عنوان شاخصی برای اندازه‌گیری کارایی یا مقایسه میان تیم‌های متفاوت استفاده کرد. علاوه بر این، استفاده از این کمیت برای مقایسه بین تیم‌ها سبب ایجاد یک بازی‌ شده که در این بازی، بی‌شک طرف پیروز، اغراق در برآورد و تمرکز بر کارهای درون‌تیمی به جای همکاری میان‌تیمی خواهد بود.سنجش بهره‌گیری (utilization) به عنوان معیاری برای بهره‌وری (productivity) چطور؟ ایراد این روش این است که بالا بردن بهره‌گیری تا حدی خوب است. به حداکثر رساندن بهره‌وری به این معنی است که هیچ ظرفیت خالی‌ای نداریم. بنابراین، نمی‌توانیم کارهای برنامه‌ریزی نشده، تغییرات یا کارهایی را که منجر به بهبود فرایند می‌شود، بپذیریم. در نتیجه، زمان انجام کار افزایش پیدا خواهد کرد.ایراد اساسی روش‌های توضیح داده شده، تمرکز بر خروجی‌ها (output) به جای پیامدها (outcome) است. خروجی چیزی است که به مشتری تحویل می‌دهیم و پیامد، ارزشی است که مشتری دریافت می‌کند (مطالعه‌ی بیشتر). همچنین شاخص جایگزین باید به شکلی انتخاب شود که منجر به رقابت ناسالم میان تیم‌ها نشود. کتاب، چهار کمیت برای اندازه‌گیری کارایی معرفی می‌کند:۱. زمان تحویل (delivery lead time)۲. فرکانس استقرار (deployment frequency)۳. زمان بازیابی سرویس (time to restore service)۴. نرخ شکست تغییرات (change failure rate)بر این اساس سوالاتی طراحی شده تا میزان تأثیر این شاخص‌ها را روی کارایی تحویل نرم‌افزار، مشخص کند. جداول زیر نتیجه‌ی این پژوهش در سال‌های ۲۰۱۶ و ۲۰۱۷ را نشان می‌دهند.اولین نکته‌ای که در این آمار جلب توجه می‌کند این است که هیچ مصالحه‌ای (tradeoff) میان بهبود کارایی و دستیابی به سطوح بالاتر کیفیت و پایداری وجود ندارد. در حقیقت، تیم‌هایی کارآمدتر در همه‌ی جنبه‌ها از سایرین پیشی گرفته‌اند. احتمالاً چنین عباراتی برای شما آشنا هستند:«نوشتن تست خوب است؛ اما باعث می‌شود کار دیرتر به نتیجه برسد.»«خودکارسازی خوب است؛ اما وقت نداریم.»«مدام خطاهای محیط عملیاتی با تغییرات انسانی برطرف می‌شوند.»...این‌ها همه مثال‌هایی هستند که نشان‌دهنده‌ی طرز تفکری است که بهبود کیفیت و پایداری را در تناقض با بهبود کارایی می‌بیند. نکته‌ی شگفت‌انگیزتر این است که ادامه‌ی مطالعات در سال‌های بعد نشان می‌دهد تیم‌هایی که در گروه کارآمد هستند، نه‌تنها بهتر عمل می‌کنند، بلکه با گذشت زمان فاصله‌ی بیشتری از سایرین می‌گیرند. فرهنگ؟ اندازه‌گیری؟ مگر داریم؟ مگر می‌شود؟!خواندن این بخش از کتاب بسیار برای من جالب و مطالب موجود در آن، بسیار شگفت‌آور بود. تصور اندازه‌گیری چیزی مثل فرهنگ، غیرممکن بود؛ اما با خواندن مطالب کتاب متوجه شدم که با مدل‌سازی درست و طرح سوالات سنجیده چنین کاری نه‌تنها غیرممکن نیست، بلکه می‌تواند به شکلی کاربردی انجام شود.مدل فرهنگ سازمانی وسترومپژوهش‌گران از مدل فرهنگ سازمانی وستروم (Westrum) برای مدل‌سازی فرهنگ استفاده می‌کنند. بر اساس این مدل، سازمان‌ها در سه دسته قرار می‌گیرند:۱. بیمار‌گونه (pathological) / مبتنی بر قدرت: میزان وجود ترس و تهدید در بدنه‌ی سازمان، چنین سازمانی را مشخص می‌کند. افراد معمولا اطلاعات را به دلایل سیاسی نشر نداده یا آن را تغییر می‌دهند تا بهتر به نظر برسند.۲. بوروکراتیک / مبتنی بر مقررات: از بخش‌های (department) خود حمایت می‌کنند. افرادِ داخل یک بخش، از «خاک» خود دفاع می‌کنند، به مقررات خودشان اصرار دارند، و معمولاً بر اساس مقررات عمل می‌کنند (البته، مقررات خودشان).۳. مولد / مبتنی بر کارایی: سازمان‌هایی که بر مأموریت تمرکز می‌کنند. همه چیز به کارایی خوب بستگی دارد؛ به کاری که قرار است انجام دهیم.مدل وستروم به چه درد می‌خورد؟مدل وستروم، چگونگی جریان اطلاعات درون سازمان را پیش‌بینی می‌کند. این نظریه ادعا می‌کند سازمان‌هایی که در آن اطلاعات بهتر جریان دارد، بهتر عمل می‌کنند. فرهنگ خوب، پیش‌نیازهایی دارد که با پرداختن به آن‌ها، ویژگی‌های فرهنگ خوب هم مشخص می‌شود.برای داشتن فرهنگ خوب، به اعتماد و همکاری میان افراد در بخش‌های مختلف سازمان نیاز داریم. بنابراین فرهنگ خوب، نشان‌دهنده‌ی میزان همکاری و اعتماد درون سازمان است.فرهنگ سازمانی بهتر نشان‌دهنده‌ی کیفیت بهتر تصمیم‌گیری است. در چنین فرهنگی، اشتراک اطلاعات برای بهبود تصمیم‌گیری کاری خوب است. علاوه بر این، حتی اگر مشخص شود تصمیمی اشتباه است، راحت‌تر می‌توان تصمیم را برگرداند؛ چراکه به جای برخورد سلسله مراتبی و نگه‌داشتن موضوع در جمعی بسته، شفاف به آن پرداخته می‌شود.در انتها نیز می‌توان گفت تیم‌های دارای چنین فرهنگی، به علت کشف و برطرف شدن سریع مشکلات، در کار بهتر عمل می‌کنند.چطور فرهنگ را اندازه بگیریم؟برای اندازه‌گیری فرهنگ سازمانی بر اساس مدل وستروم، از پرسش‌نامه‌ی زیر استفاده ‌شده است:نکات جالبی در طراحی این پرسش‌نامه پنهان است. نکته‌ی اول این‌که گزاره‌ها به شکلی جمله‌بندی شده‌اند که افراد بتوانند نسبت به آن موضع‌گیری کنند. نکته‌ی دوم این‌که جهت به‌دست‌آمدن اطلاعات بیشتر، پاسخ‌ها طیفی از مقادیر را در بر می‌گیرد. در نهایت، سوالات به شکل هوشمندانه‌ای واقعاً جنبه‌های فرهنگی یک سازمان را هدف قرار می‌دهند. در نتیجه با پاسخ دادن به این سوالات می‌توان نوع فرهنگ سازمانی را تعیین کرد.نتیجه‌ی پژوهش نشان می‌دهد نوع فرهنگ سازمانی نه‌تنها به طور کلی با کارایی تحویل نرم‌افزار و کارایی سازمان در ارتباط است، بلکه حتی تعیین‌کننده‌ی آن نیز هست. این یافته‌ها برای نخستین بار در این کتاب مطرح نمی‌شوند. برای مثال، این مسئله در انجمن‌های DevOps کاملاً پذیرفته شده است. در واقع جنبش DevOps به یک تغییر نگاه فرهنگی تأکید دارد. استفاده از مجموعه‌ای ابزارها، به تنهایی مشکلی که DevOps تلاش می‌کند آن را حل کند، برطرف نخواهد کرد. به همین خاطر فرهنگ در انجمن‌های DevOps از اهمیت ویژه‌ای برخوردار است. آن‌چه کتاب را ارزشمند می‌کند، بررسی و تحلیل آماری جامعه‌ی نرم‌افزار است. این باعث می‌شود شیوه‌ی گفتگو از تبادل نظر و سلیقه‌گرایی به سمت اندازه‌گیری و مطرح کردن حقایق رشد کند.تا این‌جا متوجه شدیم چطور کارایی را اندازه‌گیری کنیم. دیدیم که فرهنگ سازمانی تعیین‌کننده‌ی میزان کارایی است. چگونگی اندازه‌گیری آن را هم بررسی کردیم. حالا نوبت به این سوال می‌رسد که فرهنگ سازمانی تحت تأثیر چیست و چطور آن را بهبود دهیم؟ کتاب عوامل فنی و مدیریتی را در فرهنگ سازمانی مؤثر می‌داند. عوامل فنی مؤثر در قالب مجموعه‌ای از تمرین‌ها با عنوان تحویل مستر (Continuous Delivery) و عوامل مدیریتی تحت عنوان تمرین‌های مدیریتی Lean معرفی می‌شوند.سوالی که ممکن است پیش بیاید این است که چرا عوامل تأثیرگذار، تا این حد مشخص و محدود معرفی می‌شوند؟ آیا همه‌ی عوامل فنی در قالب تمرین‌های تحویل مستمر (Continuous Delivery) قابل خلاصه‌سازی هستند؟ عوامل مدیریتی چطور؟ آیا جز این دو عامل، عامل دیگری وجود ندارد؟ این‌طور اظهارنظرها در واقع ریشه در روش علمی دارد. در حقیقت، روش علمی به این شکل است که گزاره‌ای به عنوان فرضیه در نظر گرفته شده و درستی آن مورد بررسی قرار می‌گیرد. برای مثال، فرض می‌کنیم تمرین‌های تحویل مستمر روی فرهنگ سازمانی تأثیر مثبت می‌گذارند. سپس درستی این فرضیه را بررسی کرده و میزان تأثیرگذاری را اندازه می‌گیریم.تمرین‌های فنیتحویل مستمر (Continuous Delivery) یعنی چه؟ تحویل مستمر (Continuous Delivery) مجموعه‌ای از توانایی‌هاست که به ما امکان می‌دهد انواع تغییرات —ویژگی‌های جدید (feature)، تغییرات پیکربندی، رفع خطاها، و آزمایش‌هایمان— را به شکلی ایمن، سریع و پایدار در محیط عملیاتی به دست کاربر برسانیم. پنج اصل کلیدی در تحویل مستمر (Continuous Delivery) وجود دارد:کیفیت را درون محصول قرار دهید. این عبارت در تقابل با این طرز نگاه است که کیفیت می‌تواند بعداً به محصول اضافه شود.قدم‌های کوتاه بردارید. محیط به سرعت در حال تغییر است. عمدتاً نمی‌دانیم چیز درستی را می‌سازیم یا نه. شکاندن کار بزرگ به کارهای کوچک‌تر باعث می‌شود بتوانیم خروجی را زودتر تحویل دهیم. در نتیجه زودتر می‌توانیم پیامدهای آن برای کسب و کار را اندازه‌گیری کنیم و بازخورد بگیریم. هر چند شکاندن کار به کارهای کوچک‌تر ممکن است سربار داشته باشد این سربار با پیش‌گیری از تحویل چیزی که ارزش آن صفر یا منفی است جبران می‌شود.کارهای تکراری را خودکار کنید. ماشین‌ها برای انجام کارهای تکراری مناسب‌اند و انسان‌ها برای حل مسائل. با خودکارسازی کارهای تکراری به انسان‌ها فرصت می‌دهیم وقتشان را صرف کارهایی ارزشمندتر مثل بهبود طراحی سیستم‌ها و فرایندها کنند.به دنبال بهبود مستمر باشید. مهم‌ترین ویژگی تیم‌های کارآمد قانع نبودن آن‌هاست. همیشه به دنبال بهبود هستند و آن را بخشی از کارهای روزانه‌ی خود می‌دانند.همه مسئول‌اند. در سازمان‌های بوروکراتیک هر بخش روی اهداف خود تمرکز دارد. توسعه به دنبال خروجی بیشتر، تست به دنبال کیفیت، و عملیات به دنبال پایداری است. اما در واقع همه‌ی این‌ها پیامدهایی در سطح کل سیستم هستند که تنها با همکاری بین تیمی به دست می‌آیند.آثار تحویل مستمرطی پژوهش‌ها کیفیت تحویل مستمر در تیم با اندازه‌گیری توانایی‌های زیر انجام شد.هر کدام از این توانایی‌ها در قالب سوالات چند گزینه‌ای اندازه‌گیری شدند. برای مثال، در مورد کنترل نسخه (version control) از شرکت‌کنندگان پرسیده شد تا چه حد با گزاره‌های زیر موافق یا مخالف‌اند.کد برنامه‌ی ما در سیستم کنترل نسخه ذخیره شده است.پیکربندی سیستم ما در سیستم کنترل نسخه ذخیره شده است.پیکربندی برنامه‌ی ما در سیستم کنترل نسخه ذخیره شده است.اسکریپت‌های خودکارسازی build و پیکربندی ما در سیستم کنترل نسخه ذخیره شده است.تحویل مستمر به این معنی تعریف و اندازه‌گیری شد:تیم می‌تواند استقرار در محیط عملیاتی (یا محیط کاربر) را در هر لحظه از چرخه‌ی حیات تحویل نرم‌افزار انجام دهد.بازخورد سریع در مورد کیفیت و قابل استقرار بودن سیستم برای همه‌ی تیم در دسترس است و افراد واکنش به این بازخورد را در اولویت قرار می‌دهند.همان‌طور که در شکل بالا نشان داده شده است، بررسی‌ها نشان داد که عوامل آورده شده در سمت چپ شکل تعیین‌کننده‌ی کیفیت تحویل مستمر هستند. در ادامه اثر تحویل مستمر بر تحویل نرم‌افزار و بهبود فرهنگ بررسی شده و مشخص شد تحویل مستمر دارای این پیامدهاست:افراد نسبت به سازمان خود احساس تعلقی قوی دارندسطوح بالاتری از کارایی در تحویل نرم‌افزار به دست می‌آیدنرخ شکست تغییرات پایین‌تر استفرهنگ سازمانی مولد و مبتنی بر کارایی استنکته‌ی جالبی که در اینجا نهفته است اثر تحویل مستمر بر احساس تعلق افراد به سازمان است. فرض کنید از شما پرسیده می‌شود چطور تعلق افراد به سازمان را بیشتر کنیم؟ احتمالاً در حوزه‌های غیر فنی به دنبال پاسخ این سوال هستیم؛ اما در این پژوهش نشان داده می‌شود که با به‌کارگیری روال‌های درست فنی هم می‌توان احساس تعلق افراد به سازمان را بهبود داد. با نگاهی به عوامل تأثیرگذار بر تحویل مستمر این مسأله روشن‌تر می‌شود. در سازمانی احساس تعلق بیشتر خواهد بود که افراد قدرت انتخاب و اثرگذاری بیشتری در کارشان داشته، وقتشان را صرف انجام کارهای خلاقانه به جای کارهای تکراری کرده، و همه‌ی افراد خود را در کشف و برطرف کردن مشکلات مسئول بدانند.اثر تحویل مستمر بر کیفیتبرای اندازه‌گیری کیفیت، این موارد اندازه‌گیری شد: زمانی که صرف انجام کارهای جدید، دوباره‌کاری و کارهای برنامه‌ریزی نشده، و سایر کارها شده است. نتیجه‌ی بررسی‌ها نشان داد میزان زمان صرف شده در هر مورد بین تیم‌های کارآمد و سایرین متفاوت است.تفاوت میزان وقت صرف شده در هر مورد شاید موضوع چندان عجیبی نباشد. آن‌چه جالب است صرف بیش از نیمی از وقت برای کارهای پیش‌بینی نشده و دیگر کارها حتی در تیم‌های کارآمد است. تصور بسیاری از ما این است که در جلسات برنامه‌ریزی دوره‌ای می‌توانیم و باید برآوردهای (estimate) دقیقی ارائه دهیم. این در حالی است که می‌بینیم حتی در تیم‌های موفق، نزدیک به 20 درصد از کارها غیرقابل پیش‌بینی بوده و نیمی از کارها مواردی هستند که احتمالاً ما در زمان برنامه‌ریزی در نظر نگرفته یا نمی‌توانیم در نظر بگیریم. این به آن معنی نیست که برنامه‌ریزی و برآورد را باید دور ریخت و یا نباید برای بهبود آن تلاش کرد. در عوض باید نظر داشت که ذات توسعه‌ی نرم‌افزار قرار گرفتن در یک فضای ناشناخته و دست و پنجه نرم‌کردن با مسأله است. معمولاً کاری را انجام می‌دهیم که قبلاً انجام نداده‌ایم. بنابراین انتظار ارائه‌ی برآوردهای دقیق و رسیدن ضرب‌العجل‌های (deadline) سخت‌گیرانه، غیر واقع‌بینانه است.نکته‌ی جالب دیگر این است که تفاوت میان گروه کارآمد و سایرین از میزان مورد انتظار کم‌تر بود. پاسخ به این سوال به نقل از کتاب:ما از سازمان‌ها و متخصصانی که با چیزهایی مثل مدیریت پیکربندی، زیرساخت با کد (infrastructure-as-code)، و استقرار مستمر (continuous deployment) آشنایی نداشتند، اطلاعاتی جمع‌آوری نکردیم. با جمع‌آوری نکردن داده‌های این گروه، عده‌ای که به احتمال زیاد حتی از ناکارآمدترین گروه ما بدتر عمل می‌کنند را از دست می‌دهیم.کنترل کیفیت و هیأت مشاور تغییراتیکی از یافته‌های جالب مربوط به اثرگذاری موجودیت‌های کنترل کیفیتی خارج از تیم است. این موجودیت‌ها را ممکن است با عناوینی مثل تیم کنترل یا تضمین کیفیت (QA/QC) و یا هیأت مشاور تغییرات (CAB: Change Advisory Board) بشناسید. مطالعات نشان می‌دهد:تست‌های خودکاری که توسط کنترل کیفیت نوشته شده و نگه‌داری می‌شوند یا به تیم‌های خارج از سازمان برون‌سپاری شده‌اند با کارایی فناوری اطلاعات ارتباطی ندارد.در حقیقت کیفیت زمانی بهبود پیدا می‌کند که آن را به خود تیم بسپاریم. چرا چنین چیزی مشاهده می‌شود؟ دو عامل مهم وجود دارد. اول این‌که وقتی توسعه‌دهندگان تست‌ها را بنویسند، کد قابل تست می‌شود. چون خود توسعه دهنده باید تست‌ها را بنویسد مجبور است طوری کد را بنویسد که قابل تست باشد. دوم آن‌که وقتی مسئولیت تست‌های خودکار بر عهده‌ی توسعه‌دهنده قرار گیرد، برای آن‌ها اهمیت بیشتری قائل می‌شود و انرژی بیشتری برای نگه‌داری و درست کردن خطاها می‌کند.پس آیا دیگر احتیاجی به نقش آزمون‌گر (tester) نداریم؟ جواب کوتاه این سوال خیر است. از پرداختن بیشتر به این موضوع در این‌جا صرف نظر می‌کنم. برای اطلاعات بیشتر می‌توانید به متن کتاب مراجعه کرده و یا کتاب How Google Tests Software را بخوانید.موضوع هیأت مشاور تغییرات (CAB) نیز به طور خاص مورد بررسی قرار گرفته است. در پرسش‌نامه گزینه‌های زیر در اختیار شرکت‌کنندگان قرار گرفت:تمامی تغییرات باید توسط یک موجودیت خارجی (مثل یک مدیر یا هیأت مشاور) مورد تأیید قرار بگیرد.فقط تغییرات پرخطر مثل تغییرات پایگاه داده نیاز به تأیید دارند.برای مدیریت تغییرات از بازبینی همتایان (peer review) استفاده می‌کنیم.هیچ فرایندی برای تأیید تغییرات نداریم.یافته‌ها شگفت‌انگیزند. در مورد تأثیر هیأت مشاور بر کارایی:... نیاز به تأیید، فقط برای تغییرات پرخطر با کارایی تحویل نرم‌افزار ارتباطی نداشت. تیم‌هایی که فرایند تأیید نداشتند یا از بازبینی همتایان (peer review) استفاده می‌کردند به کارایی تحویل نرم‌افزار بیشتری دست می‌یافتند. در نهایت، تیم‌هایی که نیاز به تأیید توسط موجودیت خارجی داشتند کارایی کمتری داشتند.در مورد تأثیر هیأت مشاور بر پایداری:... تأییدهای خارجی با زمان تحویل (lead time)، فرکانس استقرار، و زمان بازیابی ارتباط منفی داشته و با نرخ شکست تغییرات ارتباطی نداشتند.به زبان ساده، این موجودیت‌های خارجی نه‌تنها تأثیری بر کیفیت و پایداری ندارند بلکه باعث کند شدن کار هم می‌شوند؛ تا آن‌جا که وجود آن‌ها از نبود هیچ فرایندی هم بدتر است. این‌که چرا این اتفاق رخ می‌دهد مشخص است. سیستم‌های نرم‌افزاری پیچیده‌اند. گاهاً حتی افرادی که داخل تیم توسعه قرار دارند به همه‌ی جنبه‌های سیستم مسلط نیستند. این انتظار که فردی خارج از تیم می‌تواند ظرافت‌هایی که از دید تیم توسعه مخفی مانده را کشف کند واقع بینانه نیست. اتفاقی که در عمل می‌افتد این است که ما فرایند را دنبال می‌کنیم تا بهانه‌ای دست دیگران ندهیم. این در حالی است که می‌دانیم این فرایند در بهترین حالت بی‌اثر است و صرفاً جنبه‌ی نمایشی دارد تا آن‌که بخواهد چیزی را بررسی کند.توسعه‌ی مبتنی بر trunkتوسعه‌ی مبتنی بر trunk یکی از روش‌های مدیریت branchها در سیستم کنترل نسخه (version control) است. روش‌های مختلفی برای مدیریت branchها در سیستم کنترل نسخه وجود دارد. برای مثال ممکن است عبارات git workflow، github workfow، یا gitflow را شنیده باشید. هر کدام از این روال‌های کاری، روشی برای مدیریت branchها در سیستم کنترل نسخه ارائه می‌دهند. برخلاف این روال‌ها، توسعه‌ی مبتنی بر trunk تلاش می‌کند به جای مدیریت branchهای متفاوت، استفاده از branchها را به حداقل کاهش دهد. در توسعه‌ی مبتنی بر trunk یک branch اصلی وجود دارد که همه‌ی تغییرات به صورت روزانه در آن ادغام (merge) می‌شوند. branchها عموماً عمر کوتاهی دارند و پس از ادغام در شاخه‌ی اصلی حذف می‌شوند.بررسی‌ها نشان می‌دهد توسعه‌ی مبتنی بر trunk با کارایی بیشترِ تحویل در ارتباط است. تیم‌هایی که عملکرد خوبی داشتند حداکثر سه branch فعال داشتند و طول عمر branchهایشان خیلی کوتاه (کم‌تر از یک روز) بود. همچنین چیزی تحت عنوان دوره‌ی پایدارسازی و متوقف کردن فرایند توسعه نداشتند. این نتایج مستقل از اندازه‌ی تیم، اندازه‌ی سازمان، و صنعتی است که سازمان در آن فعالیت می‌کند.در این‌جا باز هم شاهد نکات ارزشمندی هستیم: طول عمرهای به شدت کوتاه، تعداد branchهای فعال خیلی کم، و فراگیر بودن مطالعات. با این‌حال ممکن است افرادی که Github یا سیستم‌های مشابه کار کرده‌اند نسبت به این مشاهدات بدبین باشند. نکته‌ی کلیدی در این‌جا این است که توسعه‌ی مبتنی بر trunk بر طول عمر کوتاه branchها تأکید دارد. مادامی که این شرط برقرار باشد، هر روال کاری که مورد استفاده قرار گیرد از مزیت‌های این روش بهره‌مند خواهد شد.چرا تعداد زیاد branch بد است؟ تعداد زیاد branch به معنی تعداد زیاد کارهای باز است. وقتی با تعدادی زیادی branch روبرو هستیم، این احساس را داریم که در حال انجام مقدار زیادی کار هستیم، در حالی که هیچ یک از آن‌ها واقعاً عملیاتی نشده‌اند. با کم کردن تعداد branchهای فعال تلاش می‌کنیم زمان رساندن یک تغییر به محیط عملیاتی را کاهش دهیم. از سوی دیگر، هر branch در سیستم کنترل نسخه از سایر branchها جداست. یعنی که تغییراتی که در یک branch اعمال می‌شود، برای سایر branchها قابل مشاهده نیست. تنها زمانی که یک branch در شاخه‌ی اصلی ادغام شود، این تغییرات آشکار می‌شوند. هر چه تعداد branchها بیشتر باشد، میزان این تغییرات نهفته بیشتر خواهد بود. در نتیجه احتمال و پیچیدگی تعارض‌ها (conflict) نیز افزایش پیدا می‌کند.چرا عمر زیاد branch بد است؟ هر چه طول عمر یک branch بیشتر باشد، به معنی فاصله گرفتن بیشتر آن از شاخه‌ی اصلی است. ممکن است تصور کنیم اگر در فواصل زمانی کوتاه، تغییرات را از مخزن اصلی بگیریم این مسئله حل می‌شود؛ اما مسئله این‌جاست که همواره در حال پرداخت هزینه‌ی این فاصله گرفتن از شاخه‌ی اصلی هستیم. از سوی دیگر هر چه طول عمر branch بیشتر باشد، احتمالاً تغییرات بیشتری در آن انجام شده است. بنابراین زمانی که تغییرات را در شاخه‌ی اصلی ادغام کنیم به سایر اعضای تیم هزینه‌ی ادغام سنگینی وارد خواهد شد.«اما اگر همیشه تغییرات را در مخزن اصلی ادغام کنیم، نرم‌افزار ناپایدار می‌شود...» نتیجه‌ی مطالعات این را نشان نمی‌دهد. در حقیقت خلاف این را نشان می‌دهد؛ اما این به معنی نیست که اگر همه‌ی تغییرات را در شاخه‌ی اصلی ادغام کنیم، به صورت خودکار محصول پایدار می‌شود. توسعه‌ی مبتنی بر trunk در کنار استفاده از سایر تمرین‌های تحویل مستمر به ما کمک خواهد کرد به این هدف دست پیدا کنیم.برای مطالعه‌ی بیشتر در زمینه‌ی روش‌های مدیریت branch می‌توانید به این مقاله از مارتین فاولر مراجعه کنید.ویژگی‌های معماریتا این‌جا از آثار به‌کارگیری تمرین‌های تحویل مستمر (continuous delivery) بر فرهنگ، کارایی و ... صحبت کردیم. با این‌حال ممکن است با خود بگوییم:«همه‌ی این‌ها درست است، اما در سازمان ما یا پروژه‌ی ما یا در نوع پروژه‌هایی که ما انجام می‌دهیم جواب نمی‌دهد. DevOps و تحویل مستمر برای سیستم‌های مبتنی بر وب طراحی شده‌اند در حالی که ما روی یک نرم‌افزار یک‌تکه (monolithic) که روی mainframe اجرا می‌شود کار می‌کنیم.»این بخش از پژوهش تلاش می‌کند تأثیر تصمیمات و محدودیت‌های معماری را بر تحویل نرم‌افزار در محیط‌های متفاوت بررسی کرده و ویژگی‌های معماری مؤثر را شناسایی کند. یافته‌ها نشان می‌دهد... دستیابی به کارایی بالا در همه‌ی انواع سیستم‌ها امکان‌پذیر است، به شرطی که سیستم و تیم توسعه‌دهنده و نگه‌دارنده‌ی آن، دارای وابستگی‌های سست (loose coupling) باشند.انواع سیستم‌هایی که طی پژوهش مورد بررسی قرار گرفتند به شرح زیرند.زمین سبز (greenfield): سیستم‌های جدیدی که هنوز منتشر نشده‌اندسیستم‌های سرگرمی (مورد استفاده‌ی مستقیم کاربران)سیستم‌های ثبت و ضبط (برای ذخیره‌سازی اطلاعات حیاتی کسب و کار که در آن صحت و سازگاری اطلاعات اهمیت دارد)نرم‌افزار سفارشی که توسط شرکت دیگری توسعه داده می‌شودنرم‌افزار سفارشی داخلینرم‌افزار تجاری از پیش‌آماده و بسته‌بندی شده (commercial off-the-shelf)نرم‌افزار تعبیه‌شده (embedded) که روی دستگاه سخت‌افزاری تولید شده اجرا می‌شودنرم‌افزارِ دارای مولفه‌ای که توسط کاربر نصب می‌شود (شامل برنامه‌های موبایل)نرم‌افزار غیر mainframe که روی سرورهای شرکت دیگری اجرا می‌شودنرم‌افزار mainframeیافته‌ها نشان می‌دهد... گروه‌های ناکارآمدتر بیشتر می‌گفتند نرم‌افزاری که می‌سازند یا سرویس‌هایی که با آن تعامل دارند نرم‌افزاری سفارشی است که توسط شرکت دیگری توسعه داده می‌شود... همچنین تعداد بیشتری از آن‌ها روی سیستم‌های mainframe کار می‌کردند. به طرز جالبی یکپارچه (integrate) کردن تغییرات در سیستم‌های mainframe ارتباطی با کارایی نداشت.در سایر موارد ارتباط چشم‌گیری بین نوع سیستم و کارایی تحویل وجود نداشت.این یافته‌ها شگفت‌آور است و نشان می‌دهد حتی در سیستم‌های بسته‌بندی شده و میراثی، می‌توان از مزیت‌های معماری با وابستگی سست بهره‌مند شد. همچنین در مقابل، استفاده از آخرین نسخه‌ی معماری microservice یا استفاده از container برای استقرار تضمینی برای بهبود کارایی نیست. آن‌چه بر کارایی اثرگذار است ویژگی‌هایی است که در ادامه به آن خواهیم پرداخت.تمرکز بر قابل استقرار و قابل تست بودنبرای بررسی قابل استقرار و قابل تست بودن گزینه‌های زیر در پرسش‌نامه قرار گرفت. تیم‌هایی که با عبارات زیر موافق بودند به احتمال بیشتری در دسته‌ی کارآمد قرار می‌گرفتند.بیشتر تست‌های ما بدون نیاز به محیط یکپارچه قابل اجراست.می‌توانیم برنامه‌مان را مستقل از برنامه‌ها یا سرویس‌هایی که به آن‌ها وابستگی دارد، استقرار داده یا انتشار دهیم و از این امکان استفاده می‌کنیم.این دو ویژگی را قابل تست و قابل استقرار بودن می‌نامیم. این ویژگی‌ها حاصل تصمیم‌هایی در سطح معماری هستند. برای دست‌یابی به این ویژگی‌ها طراحی باید به شکلی باشد که وابستگی‌ها سست باشند. یعنی تغییر و اعتبارسنجی (validation) بخش‌های مختلف سیستم، باید بتواند به صورت مستقل از هم انجام شود. بررسی‌ها نشان می‌دهد موارد زیر، مهم‌ترین عوامل در تحویل مستمر هستند؛ حتی مهم‌تر از خودکارسازی تست و استقرار.تیم می‌تواند تغییرات طراحی در مقیاس بزرگ را بدون نیاز به اجازه‌ی فردی خارج از تیم انجام دهد.تیم می‌تواند تغییرات در مقیاس بزرگ را در طراحی سیستم خود انجام دهد؛ بدون این‌که نیاز به تغییر در سیستم دیگری باشد یا کار زیادی برای سایر تیم‌ها ایجاد کند.تیم می‌تواند کار خود را بدون نیاز به ارتباط و هماهنگی با افراد خارج از تیم انجام دهد.تیم می‌تواند بدون در نظر گرفتن سایر سرویس‌های وابسته، سرویس یا محصول خود را در لحظه (on demand)، استقرار یا انتشار دهد.تیم می‌تواند بیشتر تست‌های خود را در لحظه و بدون نیاز به محیط یک‌پارچه انجام دهد.تیم می‌تواند استقرار را در ساعات اداری با زمان قطعی (downtime) ناچیز انجام دهد.این موارد ویژگی‌های سیستمی است که وابستگی‌های سست دارد. اما چطور به این نقطه برسیم؟ برای دست‌یافتن به این قابلیت، به تیم خودکفا (cross functional) نیاز داریم؛ تیمی که تمامی مهارت‌های مورد نیاز طراحی، توسعه، تست، استقرار، و عملیات در آن وجود دارد. هدف این است که تیم بتواند کار خود را از مرحله‌ی طراحی تا استقرار، بدون نیاز به تعاملات بین تیمی زیاد انجام دهد.پس DevOps چه شد؟ DevOps ما را تشویق به ارتباطات بهتر بین تیمی می‌کند. تیم خودکفا نمی‌خواهد ارتباطات بین تیمی را حذف کند. وابستگی‌های سست باعث می‌شود بتوانیم در تعاملات بین تیمی به جای پرداختن به جزئیات، بر اهداف مشترک تمرکز کنیم.سخن پایانیآن‌چه خواندید بخشی از نکات برجسته و ارزشمند کتاب Accelerate بود. موارد زیادی بود که در این مطلب فرصت پرداختن به آن را پیدا نکردم. به طور خاص به تمرین‌های مدیریتی و مسائل پیرامون آن مثل رضایت کارمندان، رهبری و ... نپرداختم. به بخش روش تحقیق نیز پرداخته نشد و خواننده‌ی علاقه‌مند می‌تواند توضیحات بیشتر را با مراجعه به کتاب پیدا کند.به نظر می‌رسد مطالب ارائه شده در کتاب، پشتوانه‌ی قوی علمی و پژوهشی داشته باشد. یافته‌ها شگفت‌انگیز هستند. اظهار نظرها بعضاً جسورانه هستند؛ اما تلاش شده با مطالعه‌ی گسترده جای بحث و گمان به حداقل برسد. با این حال ممکن است به بخش‌هایی از آن مشکوک بوده یا کاملاً با آن مخالف باشید. ممکن است با خود بگویید حتی اگر چیزی در اکثریت یک جامعه‌ی آماری برقرار باشد، به معنی جهان‌شمولی آن نیست و شاید در سازمان ما جواب ندهد.ممکن است حق با شما باشد. آورده‌ی اصلی این کتاب، تنها یافته‌های آن نیست. آن‌چه خواندن این کتاب را ارزشمند می‌کند نوع نگاه و روش علمی پرداخت به موضوع است؛ اظهار نظر بر اساس اندازه‌گیری و جمع‌آوری اطلاعات، به جای ادعا و اعمال سلیقه. آزمایش‌ها قابل تکرار هستند. می‌توانید پرسش‌نامه‌ها را در سازمان خود پخش کرده و نتایج را ببینید. نتیجه هر چه که باشد، با اتکا به جمع‌آوری داده و اندازه‌گیری، در مسیر بهتری قرار خواهید گرفت. تِک‌بلاگ سحاب سید مرتضی هاشمی Fri, 18 Dec 2020 16:30:20 +0330 https://virgool.io/SahabPardaz/%D8%AF%D8%B1-%D8%A8%D8%A7%D8%A8-%DB%8C%DA%A9-%D9%85%D8%AD%D8%B5%D9%88%D9%84-%D8%AC%D8%AF%DB%8C%D8%AF-%DA%86%D9%87%D8%B7%D9%88%D8%B1-%D8%AF%D8%B1-%DA%AF%D9%88%DA%AF%D9%84-%D8%B3%D8%A7%D8%AE%D8%AA%D9%87-%D9%85%DB%8C%D8%B4%D9%87-jkfhhph5zcvn این هفته در شرکت ما «هفته‌ی نوآوری» است و بهانه‌ایست برای پرداختن به پرسشی که در عنوانِ این نوشته آمده. البته من شخصا از ناآگاه‌ترین افراد برای پاسخ به این پرسش‌ام چون در تیم‌های فنی و دور از محصول بوده‌ام، ولی نکاتی هست که شاید به درد بخوره.چه محصول جدیدی از بیخ، یا (از اون متداول‌تر) چه قابلیت‌های جدیدی برای محصولاتمون، در بازار جاش خالیه و با استراتژی آینده‌ی شرکت ما هم‌گامه؟ پاسخ این پرسش از کجاها می‌آد؟پاسخ کوتاه: از همه جا. از تیم‌های مدیر محصول (product manager)، از کفِ تیم‌های فنی (پایین به بالا)، از حلقه‌های اول مدیریتی (بالا به پایین)، و ...اول، مثل بسیاری جاهای دیگر، در کنار تیم‌های مهندسی تیم‌هایی هم از مدیر محصول یا PM وجود دارند که از وظایف اصلی‌شون بررسی بازار و مطالعه‌ی کاربران و نشست و برخاست با شرکا (partners) و افکارسنجی و کارهای از این دست است. نتیجه، پیشنهادهایی‌ست تا با رهبران فنی و (بسته به بزرگیِ ایده) مدیران رده بالاتر تا VP و SVP و غیره به بحث گذاشته بشه.توجه کنید که این کار، بخشی از شرح وظایف تیم‌های مدیر محصول است ولی نه حوزه‌ی استحفاظی‌شون، یعنی «ما تو کار فنی دخالت نمی‌کنیم شما تو کار مدیر محصولی دخالت نکنید» و «این تیم صاحب what باشه و اون تیم صاحب how» و این شکل نگاه قلمروی باب نیست. این شاید بدیهی باشه ولی برای این می‌گم که یکی از متداول‌ترین پرسش‌هایی که در گپ و گفت‌ها با هم‌کاران در بازار ایران می‌شنوم درباره‌ی ساختار سازمانی و «چه تیمی به چه تیمی ابلاغ کنه فلان کارو بکن» است.دوم، مهندسان فنی هم در کنار کار فنی تشویق می‌شن برای نوآوری و ایده دادن برای محصول یا قابلیت جدید. ساز و کار اصلی برای این کار، یک مرکز رشد (incubator) درون‌سازمانی برای کمک به «تبدیل ایده به محصول» است - برای اطلاعات بیشتر جستجو کنید Google area 120. کارکنان می‌تونن ایده رو به اونجا ارسال کنن و راهنمایی و حمایت و منابع بگیرن تا ایده به جایی برسه.صاحبِ حقوق معنوی ایده، گوگل است. یعنی اصلا از این حرف‌ها که شخص «شریک» باشه و درصدی از سودِ احتمالی رو بگیره و اینا نداریم. این رو می‌گم چون باز معمولا این از اولین سوال‌هاییست که وقتی صحبت area 120 می‌شه ازم پرسیده شده. البته نفع‌های دیگه‌ای برای فرد داره، هم از نظر شغلی و هم مالی، ولی مدلِ شراکتی نه.در همین راستا: شما به عنوان کارمند گوگل چه تمام‌وقت چه ساعتی، اگر در اوقات فراغت خودتون و با منابع خودتون هم کسب و کاری راه بندازید در حوزه‌ای که به حوزه‌های کاری گوگل مربوطه (یعنی تقریبا هر گوشه‌ای از دنیای فن‌آوری)، حقوق مادی و معنوی‌اش کاملا متعلق به گوگل است نه به شما و نه حتی شریکی.«هفته‌ی نوآوری» که در بالا اشاره شد نیز ساز و کار دیگر و کوچک‌تری در راستای تشویق کارکنان به نوآوری‌ست که البته فقط در چند دفتر مرسومه نه در سرتاسر گوگل: یک هفته ماراتنِ کار برای تبدیل ایده به MVP.کسانی که ایده‌ای دارند از پیش در یک لیست ثبت می‌کنند. کسانی که علاقمند به شرکت هستند یکی از ایده‌ها رو بنا به علاقه برای همکاری انتخاب می‌کنن و در هفته‌ی نوآوری انحصارا روی اون ایده همکاری می‌کنن. یعنی کار روزمره‌ی تیم خودشون تعطیل. مدیران همه‌ی تیم‌ها هم حامی شرکت کردنِ اعضاشون در این برنامه هستند و تشویق می‌کنند. ایده‌ها می‌تونه به سادگی «سیستم سفارش دهی در کافه‌ی طبقه‌ی پایین رو دیجیتال کنیم» باشه یا واقعا یک محصول یا قابلیتِ خط‌شکنِ جهانی، فقط باید بشه در یک هفته با چند نفر به یه جایی رسوندش.سوم، محصول‌ها یا قابلت‌های بزرگ و سطح بالا، معمولا نه در سطح مدیر محصول گرفته می‌شه و نه مهندسان فنی، بلکه در رده‌های بالاترِ مدیریتی تا خود شخص CEO - بخشی از وظایف حلقه‌ی اول مدیریتی همینه که به چه زمینه‌هایی ورود کنیم. مثلا این که گوگل یک سرویس پیام‌رسان داشته باشه---علی‌رغم این که پشت در پشت هم شکست بخوره---تصمیمِ مستقیم حلقه‌ی اول مدیریتی‌ست. حتی این تصمیم که پیام‌رسان گوگل مثل بچه‌ی آدم با شماره تلفن کار نکنه بلکه با Google ID کار کنه هم همین‌طور، که باعث شد پیام‌رسان Hangouts فراگیر نشه و شکست بخوره. یا مثلا این که محصول Chrome هم به Safari و Firefox بپیونده و cookieهای شخص ثالث رو بازنشسته کنه، تصمیمی که دهان محصولات تبلیغات خود گوگل رو سرویس خواهد کرد، در رده‌ی شخص Sundar گرفته شده برای حفظ بِرَند گوگل. همچنین سایر تصمیماتی که در دنیای بیرون دیده‌شدنی‌تر هستند مثل پروژه‌ی Google Fiber یا شهرِ هوشمندِ Sidewalk Labs.دیگه؟ خیلی از محصولات گوگل حاصل خریدن شرکت‌های دیگه هستن. از قضا فعالان زیست‌بومِ استارتاپی، سر این قضیه از گوگل و سایر شرکت‌های بزرگ شاکی‌اند چون می‌گن از قدرتش سواستفاده می‌کنه: اگر یک کسب و کار چشمش رو بگیره (غیر مستقیم)‌ بهشون می‌گه یا باید به من بفروشید یا عین محصولتون رو می‌زنم و صد برابر شما منابع دارم. بگذریم.دیگه؟ معمولا تصور از «محصول‌ها»، زیرمجموعه‌ای از محصول‌هاست که می‌رسه دست کاربر، ولی بسیاری از محصول‌های هر شرکتی بزرگی، درونِ سازمان تعریف می‌شن و انجام می‌شن و دست به دست هم می‌دن تا اون زیرمجموعه‌ی کوچک از محصول‌ها که در بیرون دیده می‌شه به وجود بیاد. برخی مصولات گوگل به ویژه در حوزه‌ی خدمات ابری، سرویس‌های درونی خود گوگل هستند که با زحمت فراوان قابل عرضه به دنیای بیرون می‌شن - عقلی که آمازون از اول در طراحی سرویس‌های داخلیش کرد و گوگل نکرد. مثال: Dremel که شد BigQuery، یا Borg که شد Kubernetes، یا Forge که شد Cloud Build،‌ یا Monarch که شد Cloud Monitoring.دوست داشتم کمی هم از «تولید چه‌طور آغاز می‌شه / نیرو و تیم چه طور اختصاص داده می‌شه» بگم ولی گفتار طولانی شد و خلاصه‌ش می‌کنم:انتسابِ کار در گوگل و احتمالا شرکت‌های مشابه، برخلاف شرکت‌های پیشینی که باهاشون هم‌کاری داشتم، بیشتر pull based است تا push based، هم در رده‌های مدیریتی و هم فردی. یعنی اگر ایده‌ی نون و آب داری از طرف مدیرمحصول‌ها یا استراتژیست‌ها و مدیران رده بالا مطرح بود، قطعا روی زمین نمی‌مونه و حتی سرِ گرفتنش دعواست.ایده‌هایی که از خودِ تیم‌های فنی جرقه می‌خوره معمولا در همون تیم نیرو می‌گیره و آغاز می‌شه، فقط طبیعتا باید ارزشش توجیه بشه و در OKR planning بحث بشه و ... روال معمول.برخی محصول‌ها در مرکز رشد area 120 که بالاتر گفتم آغاز شدن و به جایی رسیدن.پروژه‌های ۲۰٪ی که احتمالا درباره‌ش شنیدید واقعا کار می‌کنند. ۲۰٪ی یعنی هر کارمند می‌تونه ۲۰٪ از وقتش رو روی پروژه‌ای نامرتبط به کارهای اصلیش کار کنه، یا ایده‌ی خودش یا همکاری با تیم‌های دیگر - برای اطلاعات بیشتر جستجو کنید Google 20% project. البته شوخی متداول اینه که می‌گن اگر پروژه‌ی ۲۰٪ی برداری یعنی باید ۱۲۰٪ کارکنی و خالی از حقیقت هم نیست، ولی قابل انجامه. محصول کامپیوتر کوانتومی گوگل که پارسال خط‌شکنی بزرگی کرد و در خبرها معروف شد، اگر اشتباه نکنم از یک پروژه‌ی ۲۰٪ی آغاز شد. باز اگر اشتباه نکنم، Street View هم همین‌طور. GMail هم همین‌طور. اصلا یکی از پروژه‌های اصلی من و تیممون در حال حاضر هم از ۲۰٪ی آغاز شد، بعدش باز چند نفر از بیرونِ تیممون به شکل ۲۰٪ی درش همکاری کردن. راه انداختن این ساز و کار توصیه می‌شه.احتمالا نکات بسیاری رو جا انداختم ولی امیدوارم به درد هم‌کاران بخوره. تِک‌بلاگ سحاب Kian Fri, 04 Dec 2020 01:23:50 +0330 https://virgool.io/SahabPardaz/%D8%AA%D8%AD%D9%88%DB%8C%D9%84-%D9%85%D8%B3%D8%AA%D9%85%D8%B1-kuaqvk8r1r4s چندی پیش، کتاب تحویل مستمر (Continuous Delivery) را با گروهی از همکاران خوانده و جلسات گپ‌وگفتی پیرامونش داشتیم. برای من کتاب پرفایده و تاثیرگذاری بود. پیش‌تر هم درباره‌ی برخی از سرفصل‌های این کتاب چیزهایی شنیده یا خوانده بودم؛ اما خواندن این کتاب کمک کرد تا ساختاری منظم‌تر از موضوع در ذهنم شکل گرفته و با الگوها، ضدالگوها و تکنیک‌های بیشتری آشنا شوم. به خاطر دارم که کمی بعد، وقتی جلساتی در شرکت با حضور نماینده‌هایی از تیم‌های مختلف برای تدوین مدل بلوغ کیفیت تولید نرم‌افزار داشتیم، یکی از کتاب‌هایی که ارجاعات فراوانی به آن می‌شد و راهگشایمان بود، همین کتاب بود. بارها برای من پیش آمده که مطالب این کتاب در جریان بهبود فرآیند‌های توسعه‌مان بکار آید از جمله وقتی می‌خواستیم تست‌های پذیرش (acceptance) و کارایی (performance) را در سبد تست‌های خودکار محصولاتمان قرار دهیم و یا این اواخر وقتی می‌خواستیم مقدمات فنی تجزیه یک تیم بزرگ را آغاز کنیم؛ یعنی در راه شکستن یک سیستم بزرگ به چندین زیرسیستم که هر کدام حیطه‌ی کسب و کاری (business) مشخصی را هدف قرار دهند و هر کدام مولفه‌ها و پایپلاین استقرار (deployment pipeline) مستقل خود را داشته باشند. اما برویم سراغ کتاب.جهنم چه شکلی است؟اگر بخواهم درباره‌ی این کتاب صحبت کنم به نظر من بی‌شک پرده‌ی اول، تصویری از جهنم تیم‌های توسعه است. در جهنم توسعه‌دهنده‌ها، استقرار مولفه‌های نرم‌افزاری و مهیا کردن اولیه‌ی محیط آن‌ها به شکل دستی انجام می‌‌شود. فقط چند نفری هستند که فوت‌و‌فن این کار را می‌دانند؛ اما خود آن‌ها هم با دعا و ثنا کار را پیش می‌برند. به همین جهت است که از گام‌های استقرار، اتفاقات بدی که در حین آن می‌تواند بیفتد و راه‌حل‌هایش، سند مفصلی می‌سازیم؛ اما گویی با هر استقرار جدید با مشکلات و ناهماهنگی‌های تازه‌ای روبرو می‌شویم تا همواره سطح آدرنالین خونمان بالا بماند. گاهی خطاهایی داریم که آن‌ها را ظرف چند دقیقه برطرف کرده‌ایم؛ اما دو سه ساعت پراضطراب برای استقرار آن باید کار کنیم! در جهنم، خیلی از تست‌ها را به شکل دستی انجام می‌دهیم؛ اما وقت نمی‌کنیم همه‌ی آن‌ها را در همه‌ی ریلیزها دوباره چک کنیم، پس به اندکی از آن‌ها بسنده می‌کنیم؛ اما محیط عملیاتی گاه‌و‌بیگاه خطاهای جدیدی برایمان رو می‌کند. برخی خطاهایی که سابقا درست کرده بودیم ظاهرا دوباره برگشته؛ اما چه کنیم؟ ما نمی‌توانیم نبود همه خطاهای قبلی‌ خود را در همه‌ی ریلیزها دوباره به شکل دستی چک کنیم!ما یک محیط آزمایشگاهی داریم. اینقدر هم ساده‌دل نیستیم که همه چیز را اولین بار در محیط عملیاتی آزمایش کنیم؛ اما هر از چند گاهی می‌بینیم که آنچه در محیط آزمایشگاهی موفق بوده، در محیط عملیاتی با خطا مواجه می‌شود. از واکاری ریشه‌ی خطا در می‌یابیم که کانفیگ این دو محیط متفاوت است. این دو محیط با روال یکسانی کانفیگ نشده‌ و هر کدام به شکل دستی و با ترتیب و تاریخچه‌ای متفاوت برپا شده‌اند. تنظیمات پایگاه داده، اپ سرورها و سیستم‌عامل‌ها متفاوت است. گاهی خطاهایی حیاتی گزارش شده و باید به سرعت برطرف شود؛ اما واقعا عقلمان قد نمی‌دهد که مشکل چیست. پس باید تغییرات اخیر را بازگردانیم (rollback) که البته اضطرابش کمتر از استقرار اولیه‌ی این تغییرات نیست.در جهنم معمولا تصمیماتی می‌گیریم که شرایط را بدتر می‌کند. چون تست نکرده‌ایم، زمان ریلیز را عقب می‌اندازیم. چون زمان ریلیز را عقب می‌اندازیم کارهای جدیدی اضافه شده که آن‌ها هم تست می‌خواهند. بسته‌ای که در ریلیز قرار می‌گیرد، بزرگ شده و ریسک‌های بیشتری را در برمی‌گیرد. پس فیدبک‌ها با تاخیر می‌رسند؛ چه از ناحیه‌ی تسترها و چه از ناحیه‌ی مشتری‌ها. فیدبک‌ها زمانی می‌رسند که توسعه‌دهنده، دیگر آن مسئله و پیاده‌سازی‌اش را در حافظه‌ی نزدیک خود ندارد. تعاملات آدم‌ها در جهنم، خود بحث دیگری است. افراد در جهنم در سیلوهای مختلفی زندگی می‌کنند. سیلوهای مجزای مدیران محصول، برنامه‌نویس‌ها، پایگاه داده، تست، استقرار، امنیت و ... . افراد هر سیلو، بر این باورند که وظایف خود را به درستی انجام داده‌اند و سیلوهای دیگر را مقصر بروز مشکلات، دیرکردها و بحران‌ها می‌دانند. شاید فکر کنید قربانی این جهنم مشتری‌ها هستند؛ اما ترحم بر این توسعه‌دهنده‌ها جایزتر از مشتری‌هاست. اگر بگوییم مشتری‌ها حرارت این جهنم را حس می‌کنند، بی‌شک توسعه‌دهنده‌ها خود در این جهنم می‌سوزند.بهشت کجاست؟نسخه‌‌ی محصول و محیطی که می‌خواهیم آن نسخه را در آن مستقر کنیم را انتخاب کرده و دکمه‌ی استقرار را می‌زنیم. این فرآیند استقرار در بهشت است! بهشتی‌ها وقت خود را صرف کارهای تکراری نمی‌کنند. بهشتی‌ها به شدت از کارهای کسالت‌بار گریزانند؛ خصوصا اینکه یک کار هم کسالت بار باشد و هم پراسترس. و به همین علت علاقمند به خودکارسازی (automation) هستند. در اینجا، مجموعه‌‌ی کاملی از تست‌های خودکار داریم که هم اطمینان و هم سرعت در رسیدن به اطمینان را به ارمغان می‌آورند. تست‌های واحد (unit)، تست‌های پذیرش (acceptance) و تست‌های ظرفیت (capacity)، از این دسته تست‌ها هستند. در اینجا مفهوم تست، فراتر از صرف تست مولفه‌های نرم‌افزار است. همه‌ی گام‌های ما در فرآیند توسعه و تحویل نیز تحت سیطره‌ی تست‌ها قرار دارند؛ یعنی تست اسکریپت‌های ‌build و package و deploy، تست فرآیند‌های migration و rollback، تست مهیا کردن و پیکربندی (configuration) محیط‌های مختلف و ... . دقت کنید که وقتی صحبت از پیکربندی می‌کنیم، به مجموعه‌ای وسیع از امور اشاره داریم. پیکربندی یعنی آنچه در یک محیط (عملیاتی یا تستی) بنا می‌شود از جمله: توپولوژی شبکه، سیستم‌عامل‌ها، انواع کتابخانه‌ها و برنامه‌های جانبی نصب شده بر روی سیستم‌ها، سرویس‌های زیرساختی، سرویس‌های شخص ثالث (third party)، مولفه‌های محصول، مخازن و پایگاه‌های داده و خاصه تنظیمات و نسخه‌ی دقیق هر کدام از این مولفه‌ها. در بهشت، نه تنها پیکربندی به شکل خودکار انجام می‌شود بلکه اسکریپت‌های مربوط به بنا کردن یک محیط و تنظیماتی که قرار است اعمال شود، همگی شهروند درجه یک (first class citizen) هستند. آن‌ها هم مانند کدها در مخزن کد قرار می‌گیرند. بازبینی می‌شوند و تست دارند. و چون محیط‌های تست و عملیاتی با اسکریپت‌ها و روال‌های یکسانی برپا می‌شوند، کمتر پیش می‌آید که با اتفاقاتی روبرو شویم که برای اولین بار در محیط عملیاتی رو می‌شوند. آنچه در اینجا همواره می‌بینیم، تغییراتی کوچک است که به شکل خودکاری تست شده و به شکل مطمئنی تا محیط عملیاتی پیش می‌رود و روزانه بارها این روند تکرار می‌شود.در بهشت، همه خود را مسئول رساندن موفقیت‌آمیز امکانات و خدمات به مشتری‌ها دانسته و برای این کار با هم همکاری و تعامل دارند. اگر برای برآورده کردن اهداف کسب و کار لازم به تعاملات بیشتر بین برخی افراد باشد، آن‌ها به هم نزدیک‌تر می‌شوند و گاهی تا جایی پیش می‌رود که مرز بین سیلوها به کلی از بین رفته و افراد خود را در تیم واحدی با ماموریت یکسانی می‌بینند.مسیر ما به سمت بهشتمقصد مشخص است؛ اما چطور این مسیر را طی کنیم؟ سوالات و چالش‌های متعددی مطرح است:ما با تست‌های واحد، آشنایی زیادی داریم؛ اما انواع دیگری از تست‌ها هم هستند. مثلا تست‌های پذیرش (acceptance) که زبان و لحنی نزدیک به کاربران داشته و به شکل سیستمی در محیطی مشابه عملیات اجرا می‌شوند. این دسته از تست‌ها را چگونه می‌توان توسعه داد؟‌ چه الگوها و پرکتیس‌هایی برای نوشتن تست‌های پذیرش وجود دارد؟ همین سوال در مورد تست‌های کارایی (performance) و بار (load) و فشار (stress) هم مطرح است. این تست‌ها را چطور می‌شود توسعه داد و نگهداری کرد؟ و چگونه باید آن‌ها را در پایپلاین استقرار خود فراخوانی کرد؟ آیا می‌شود چک‌ها و تست‌های امنیتی را نیز به شکل خودکار و در پایپلاین استقرار انجام داد؟ برخی از این تست‌ها و تحلیل‌ها زمانگیر هستند. چطور می‌شود آن‌ها را طوری انجام داد که بتوانیم همچنان فیدبک‌های سریع و ریلیزهای متعدد و مستمر داشته باشیم؟ اگر قرار است از مزایای برخی از انواع تست‌های غیرماشینی مانند تست‌های کاوشگرانه (exploratory)، تست‌های جمعیتی (crowd testing) و dogfooding بهره ببریم، چطور می‌توانیم آن را با محیط خودکار و پرشتاب خود همراستا کنیم؟ برای استقرار تغییرات پیچیده چه راهکارها و تکنیک‌هایی وجود دارد؟ برای مثال تغییراتی را که با مهاجرت داده (data migration) یا حتی تغییر زیرساخت‌ها همراه است را چطور باید انجام دهیم؟ ...گاهی هم سوالات ما در جزییات و گام‌ها نیست. مشتاقیم با تصویر کلی (big picture) ماجرا آشنا شویم و می‌خواهیم بدانیم چگونه می‌توان این گام‌ها را به هم متصل کرده و یک پایپلاین استقرار را سروشکل داد. خوشبختانه این کتاب در هر دو جنبه‌ی یادشده گفتنی‌های زیادی برای ما دارد. به عنوان مثال در فصل ۵ با آناتومی پایپلاین استقرار آشنا می‌شویم و تصویر کلی در ذهنمان شکل می‌گیرد. فصل ۵ کتاب، صفحه ۱۱۱، آناتومی پایپلاین استقراردر مورد چالش‌های دیگر نیز به فراخور در فصل‌های مختلف بحث شده است. به عنوان مثال فصل‌های مستقلی در مورد هر یک از مباحث تست‌های پذیرش، تست‌های مربوط به ویژگی‌های غیرعملکردی (nonfunctional) و تحلیل‌های امنیتی، مدیریت داده و تکنیک‌های مربوط به مهاجرت داده‌ها، مدیریت زیرساخت‌ها و محیط و ... در نظر گرفته شده است. در این کتاب بسیاری از تکنیک‌هایی را که در ارتباط با مباحث تست، خودکارسازی و استراتژی‌های استقرار و ریلیز شنیده‌اید مرور خواهید کرد و شاید با موارد جدیدی نیز روبرو شوید. برای نمونه، به برخی از تکنیک‌هایی که در این کتاب بحث می‌شود و هر کدام می‌تواند بالقوه پاسخ یکی از چالش‌های شما باشد، اشاره می‌کنم: استقرار آبی‌-سبز (blue-green deployment) برای رسیدن به مدت پایین بودن صفر (zero downtime).ریلیز قناری (canary release) برای کاستن از میزان ریسک ریلیز و همینطور تست کردن برخی جنبه‌های کارایی که در محیط‌های غیرعملیاتی قابل انجام نیست. تست A/B برای آشنایی با ترجیحات کاربران یا مقایسه نتایج عملکرد راه‌حل‌های مختلف با هم. فلگ زدن برای ویژگی‌ها (feature flag) و شاخه زدن مبتنی بر انتزاع (branch by abstraction) برای اینکه بتوانیم هم به شکل مستمر کدهای جدید را در مخزن کد ادغام کنیم (continuous integration) و هم بتوانیم این را از دید مصرف‌کنندگان سرویس مخفی کرده و تا زمان عملیاتی شدن ویژگی‌های جدید، سرویس‌ها را به همان شکل سابق ارایه کنیم.تکنیک چرخ ضامن‌دار (ratcheting) برای وقتیکه می‌خواهیم خطاهای مربوط به تحلیل‌ها‌ی استاتیک را به صفر رسانده یا میزان پوشش تست را تا حد معینی افزایش دهیم؛ اما حجم بزرگی از کد جلوی روی‌ ما قرار دارد که نمی‌توانیم به یکباره این کار را انجام دهیم.تکنیک کش کردن لاگ‌های رخداد و ماخذ کردن رخدادها (event sourcing) به هنگام عقب‌گرد (revert) در مهاجرت داده‌ها (data migration).تکنیک استفاده از ماشین‌های مجازی (virtual machine) برای برپا کردن سریع محیط‌های تست طوریکه بتوانیم زیرساخت‌ها را با سرعت بالا بر اساس تصاویر (image) از پیش تهیه شده برپا کنیم.... گزیده‌ای از حکمت‌هااین کتاب ،چندان به ابزارها نمی‌پردازد. در برخی فصل‌ها اشاره‌ای گذرا به برخی ابزارهای متداول یک موضوع می‌کند؛ اما این صرفا از جهت آشنایی و اشاره است. تلاش اصلی کتاب، آشنا کردن مخاطب با اصول، پرکتیس‌ها، تکنیک‌ها و مهم‌تر از آن تحلیل مزایا و معایب راهکارهاست. به‌همین علت است که این کتاب که در سال ۲۰۱۰ نگاشته شده، همچنان برجسته‌ترین کتاب در حیطه‌ی مورد بحثش به حساب می‌آید. دوست دارم در پایان این نوشتار دست‌کم به عنوان نمونه هم که شده، برخی از اصول و به تعبیر من حکمت‌هایی را که در این کتاب مطرح شده، ذکر کنم. برخی از این اصول به تناسب موضوع چندین بار و در فصول مختلف کتاب تکرار شده‌اند:اسکلت و بنای اصلی پایپلاین استقرار خود را از همان ابتدای پروژه شکل دهید.مراحل پایپلاین را بر اساس ایده سریع شکست خوردن (fail fast) بنا کنید.از شاخه اصلی کدبیس فاصله نگیرید. تغییراتی کوچک داشته باشید که به شکل مستمر در کدبیس ادغام می‌شوند.همه چیز را در مخزن کد قرار دهید: کد، مستندات، اسکریپت‌های تولید مولفه‌ها و استقرار، تنظیمات محیط‌های مختلف، ... .خودکارسازی را بر مستندسازی ترجیح دهید. چیزی که خودکار شده مستند، قابل ارزیابی و بازبینی، تکرار پذیر و با سرعت قابل اجراست و چون باید قابل اجرا باشد، به‌روز هم هست. انجام شده (done) به معنای منتشرشده در محیط عملیاتی (released) است و در غیر این‌ صورت، کار به پایان نرسیده است.هر نسخه از آرتیفکت‌های باینری شما باید تنها یکبار ساخته شود. ساختن مجدد یک نسخه از آرتیفکت برای استفاده در محیط‌های مختلف خطاست.اطمینان یابید که فرآيند استقرار شما، غیرحساس به تکرار (idempotent) است.تا جای ممکن استقرار موضوعات مختلف را همزمان نکنید. به عنوان مثال ویژگی‌های جدید و مهاجرت داده را همزمان نکنید.این بود معرفی کوتاه من از کتاب خواندنی تحویل مستمر. امیدوارم شما را به خواندن آن ترغیب کرده باشم و یا اگر آن را مطالعه کرده‌اید، این نوشتار یک یادآوری مسرت‌بخش بوده باشد. تِک‌بلاگ سحاب محمد علی بزرگ‌زاده Sun, 23 Aug 2020 11:02:43 +0430 https://virgool.io/SahabPardaz/release-it-bbc5k6annhdc خیلی از ما توسعه‌دهندگان نرم‌افزار، درد یک فرایند استقرار طولانی و دلهره‌آور را چشیده‌ایم. ممکن است پس از به پایان رسیدن این فرایند سخت، با تجربه‌ی ناخوشایند بیدار شدن از خواب با تماس‌های تلفنی مواجه شده باشیم. حتی شاید به دلیل پایین آمدن سرویس، از دست رفتن اطلاعات و یا نشت آن تا مرز از دست رفتن شغلمان پیش رفته باشیم. مایکل نایگارد در کتاب Release It تلاش می‌کند راه‌کارهایی به ما ارائه کند تا کمتر با چنین مشکلاتی برخورد کنیم. او یک مهندس نرم‌افزار است که سال‌ها در زمینه‌‌ی توسعه و استقرار سیستم­‌های نرم‌افزاری تجربه دارد. او در این کتاب چکیده‌ای از تجربیات خود را به صورت ترکیبی از داستان و درس تدوین کرده است.برای بسیاری از ما توسعه‌دهندگان، تعریف پایان کار، اضافه شدن کد به مخزن است؛ چه اضافه شدن یک ویژگی باشد و چه رفع یک خطا. توسعه‌دهندگانِ باتجربه‌تر به این بسنده نمی‌کنند. آن‌ها تا زمانی که تست نکنند، کار خود را تمام شده نمی‌دانند. عده‌ای هوشمندانه قبل از اضافه کردن کد به مخزن با اضافه کردن تست‌های خودکار، زحمت کار خود را کاهش می‌دهند. اما در نهایت، توسعه‌دهندگان اغلب پس از پاس شدن تست‌ها، کار خود را تمام شده می‌دانند. نایگارد این مسأله را به زیبایی مطرح می‌کند:شما سخت روی پروژه کار کرده‌اید. به نظر می‌­رسد همه‌­ی ویژگی‌­ها (feature) کامل شده‌­اند و حتی اکثر آن‌­ها تست هم دارند. می‌توانید نفسی راحت بکشید. کار شما تمام است.درست است؟آیا «تکمیل ویژگی­‌ها» به معنی «آمادگی برای محیط عملیاتی» است؟ آیا سیستم شما واقعاً برای استقرار آماده است؟ آیا می‌­تواند بدون شما توسط تیم عملیات اجرا شده و با هجمه­‌ی کاربران واقعی روبرو شود؟ آیا در این فکر غرق شده‌اید که دیروقت با تماس ­های اضطراری و هشدار مواجه خواهید شد؟ به نظر می‌­رسد توسعه‌ی نرم‌­افزار چیزی بیش از اضافه کردن ویژگی­‌ها باشد.در حقیقت، کار توسعه‌دهنده با پاس شدن تست‌ها تمام نمی‌شود، بلکه تازه باید برای محیط عملیاتی آماده شد. Release It شامل موضوعاتی است که توسعه‌دهنده باید برای زنده ماندن در محیط عملیاتی مد نظر داشته باشد.کتاب از چهاربخش تشکیل شده و شیوه­‌ی نگارش آن بسیار جالب است. هر بخش با یک داستان شروع می‌­شود؛ داستانی از حوادث در محیط عملیاتی؛ حوادثی که منجر به وارد شدن صدمه به دارایی‌های مالی یا معنوی ذی‌نفعان می‌شود. داستان‌ها واقعی بوده و بدون واسطه، توسط نویسنده تجربه شده‌اند؛ اما نام‌ها و جزییات تغییر داده شده تا محرمانگی حفظ شود.بخش اول «ایجاد پایداری» نام دارد. نایگارد با «اکسپشنی که یک خط هوایی را زمین زد» شروع می‌کند؛ داستان به‌­روزرسانی بخشی از یک سیستم، طی یک فرایند از قبل طراحی شده و بر اساس برنامه. در نهایت این به‌­روزرسانی منجر به بروز اختلال در سایر سیستم­‌ها از جمله سیستم صدور بلیط می‌­شود. تا زمانی که مسئله برطرف شود، هزینه­ زیادی هم از لحاظ مالی و هم از لحاظ آبروی کسب و کار، به خط هوایی وارد شده است.یکی از کارهایی که مایکل نایگارد در این کتاب انجام داده است، جمع­ آوری و نام­‌گذاری چیزهایی است که احتمالاً ما هم هنگام توسعه یا استقرار با آن برخورد کرده‌ایم. شاید هم به طور پراکنده در مورد آن مطالعه کرده باشیم؛ کاری مثل آن‌چه که کتاب الگوهای طراحی انجام داد. نایگارد ضد الگوهای پایداری را به ما معرفی می‌­کند. ضد الگوها عادت‌هایی هستند که نه تنها به پایداری سیستم کمکی نکرده، بلکه باعث تضعیف آن نیز می‌شوند.در بخش اول 12 ضد الگوی پایداری معرفی می‌شود. بعضی از این الگوها با هم ارتباط یا هم‌پوشانی داشته و یا یکدیگر را تقویت می‌کنند. بعد از مطرح کردن ضد الگوهای پایداری، نوبت به معرفی الگوهای پایداری می‌رسد. در این‌جا هم 12 الگو معرفی می‌شود که کم و بیش در تناظر با ضد الگوهای یاد شده هستند. یکی از الگوهای جالب Let It Crash است:گاهی اوقات بهترین کاری که می شود برای پایدارسازی در سطح سیستم انجام داد، رها کردن پایداری در سطح مؤلفه است. در دنیای Erlang به این روش، فلسفه «let it crash» گفته می شود. ... می دانیم که نمی توان به جلوگیری از همه خطاهای ممکن امیدوار بود. ابعاد، گسترش یافته و فضای حالت به صورت نمایی رشد می‌کند. راهی برای تست همه چیز و پیش بینی همه‌ی راه‌های شکست سیستم وجود ندارد. باید فرض کنیم که خطا رخ خواهد داد.سوال کلیدی این است، «با خطا چه کنیم؟». اغلب تلاش می کنیم شرایط را بازیابی کنیم. یعنی سیستم را با استفاده از exception handler ها و ... به یک حالت شناخته‌شده‌ی خوب برگردانیم. آیا این کافی است؟پاک‌ترین حالتی که برنامه‌ی شما می تواند داشته باشد، حالتی که درست بعد از شروع به کار دارد. رویکرد «let it crash» می‌گوید جبران خطا سخت و غیرقابل اتکاست، بنابراین هدف ما باید رسیدن هرچه سریع‌تر به آن وضعیت پاک باشد.در واقع نایگارد در این‌جا از ما دعوت می‌کند برای داشتن سیستم‌های پایدار، در شرایط خطا مولفه‌ها را هر چه سریع‌تر پایین بیاوریم!موضوع بخش بعدی کتاب «طراحی برای محیط عملیاتی» است. بارها شنیده‌ایم و دیده‌ایم که چیزی در محیط توسعه کار می‌کند اما در محیط عملیاتی با خطا مواجه می‌شود؛ جدال قدیمی میان تیم توسعه و استقرار. چیزی که نایگارد در این‌جا توجه ما را به آن جلب می‌کند تفاوت‌های محیط توسعه و محیط عملیاتی است. این تفاوت‌ها موجب بروز نگرانی‌هایی در محیط عملیاتی می‌شود. علاوه بر این، نکته‌ی دیگری که او به زیبایی به آن اشاره می‌کند در نظر داشتن افراد تیم عملیات است:طراحی برای محیط عملیاتی یعنی فکر کردن به مشکلات عملیاتی به عنوان نگرانی‌های دست اول. این مشکلات شامل شبکه محیط عملیاتی است که ممکن است بسیار متفاوت از محیط توسعه باشد. همچنین شامل لاگ زدن و نظارت (monitoring)، کنترل runtime، و امنیت می شود. طراحی برای محیط عملیاتی همچنین به معنی طراحی برای افرادی است که کار عملیات را انجام می‌دهند، چه تیم جداگانه‌ای باشند و چه در توسعه ادغام شده باشند.سپس نایگارد لایه‌های نگرانی را مطرح می‌کند. در هر لایه الفبا معرفی شده و قدم‌های بعدی برای مطالعه‌ی توضیح داده می‌شود.پس از «طراحی برای محیط عملیاتی» نوبت به «تحویل سیستم» می‌رسد. داستان این بخش «در انتظار گودو» نام دارد. در این داستان نایگارد دوتجربه‌ی متفاوت از استقرار در محیط عملیاتی را تعریف می‌کند. یکی با تلاش بیش از 40 نفر متخصص در یک بازه‌ی 24 ساعته و دومی با فشرده شدن یک دکمه توسط یک سرمایه‌گذار که در حال بازدید از شرکت بود!نایگارد از خودکارسازی استقرار، خط لوله‌ی build و استقرار مستمر (Continuous Deployment) صحبت می‌کند. او مفاهیم اصلی را به طور خلاصه مطرح کرده و برخی از ابزارهای موجود را نیز معرفی می‌کند. من به جزییات این موارد نمی‌پردازم و صرفاً به چند نکته‌ی جالب بسنده می‌کنم.یکی از نکات جالب pets vs. cattle است. در گذشته تعداد ماشین‌هایی که با آن سروکار داشتیم محدود بود. هر ماشین نقش مشخص و شناخته شده‌ای داشت. حتی گاهی تک‌تک ماشین‌ها را با اسمشان صدا می‌کردیم؛ مثل حیوانات خانگی. اما با گذر زمان تعداد ماشین‌ها بیشتر شد. نحوه‌ی کار با آن‌ها هم تغییر کرد. امروز ما با گله‌ای از ماشین‌ها مواجه‌ایم. این مسئله چطور روی کار ما تأثیر خواهد گذاشت؟ دیگر نام ماشین‌ها را نمی‌دانیم. دیگر نمی‌دانیم چه چیزی روی چه ماشینی اجرا می‌شود. دیگر از بین رفتن یک ماشین خاص برایمان اهمیت ندارد.نکته‌ی دیگری که در این فضای جدید اهمیت پیدا می‌کند رسیدگی به نسخه‌هاست. در شرایط پیچیده‌تر امروز باید بتوانیم نسخه‌های متفاوت سرویس‌ها را با یکدیگر هماهنگ نگه‌داریم. مصرف کننده‌ی یک سرویس، تیم یا محصول دیگری است. چطور نسخه‌های جدید را بدون نگرانی انتشار دهیم؟ اینجا صحبت از backward compatibility، نوشتن تست‌ها توسط مشتری و سخت‌گیری و بدبینی در تعامل با سایر سرویس‌ها است.در بخش آخر نایگارد، از «حل مشکلات سیستمی» صحبت می‌کند. در فصل اول این بخش، او از ضرورت تطبیق‌پذیری (Adaptability) صحبت می‌کند. در شرایط کنونی، مقاومت در برابر تغییر دیگر یک گزینه نیست. اکنون صحبت از کوتاه کردن چرخه‌ی بازخورد و رفع موانع است؛ این‌که چطور خود را برای استقبال از در آغوش گرفتن تغییرات آماده کنیم.در فصل بعدی نایگارد وارد موضوع مهندسی آشوب (Chaos Engineering) می‌شود. مهندسی آشوب یک موضوع نوظهور در عرصه‌ی نرم‌افزار است و طی چند سال گذشته تحولات زیادی داشته است. مهندسی آشوب تلاش می‌کند نرم‌افزار را در مقابل فجایعی که ممکن است در محیط عملیاتی رخ دهند، مقاوم کند. نایگارد این‌طور آن را معرفی می‌کند:گفتگویی را تصور کنید که این‌طور شروع می‌شود:شما می‌گویید: «سلام رئیس، من می‌خوام تو محیط عملیاتی یه تعدادی از ماشینا رو بترکونم. یه کم از اینور و یه کم از اون‌ور. نباید مشکلی پیش بیاد.»فکر می‌کنید ادامه‌ی گفتگو چطور پیش‌ خواهد رفت؟ ممکن است با مراجعه‌ی یک نفر از منابع انسانی و دستور تمیز کردن میز کارتان تمام شود. شاید هم یک قرار ملاقات با نزیک‌ترین مطب روانشناسی! پایین آوردن ماشین‌ها ممکن است یک ایده‌ی افراطی باشد، اما جنون نیست. این یک تکنیک از یک مکتب نوظهور است به نام «مهندسی آشوب».این مقدمه شاید مضحک به نظر برسد؛ اما ایده‌ی اصلی مهندسی آشوب همین است: خراب‌کاری نیمه‌کنترل شده در محیط عملیاتی! در ادامه توضیح بیشتری در مورد تاریخچه‌ی این مکتب و نگاه آن به نحوه‌ی مقاوم‌سازی سیستم‌ها داده می‌شود.آن‌چه که خواندید گوشه‌ای از مطالبی است که در کتاب Release It آمده است. خواندن کتاب و مرور دوباره‌ی آن برای نوشتن این مطلب، برای من لذت‌بخش و آموزنده بود. امیدوارم توانسته باشم این حس را در خوانندگان هم ایجاد کرده باشم. تِک‌بلاگ سحاب سید مرتضی هاشمی Sun, 05 Jul 2020 22:11:35 +0430