مهندسی داده و ام‌ال‌آپس 🚀

چقدر این دوتا تصویر، به طرز عجیبی بهم وابسته هستند . @elmedadeir

#نکته دوتا واژه داریم که خیلی عجیب بجای هم داریم استفادشون می‌کنیم ولی با هم فرق دارند: Incident & Disaster Incident (رخداد/حادثه): یک اختلال محدود و کوتاه ‌مدته که قابل مدیریت هست. مثال: ای‌پی‌آی (API) پرداخت برای ۵ دقیقه هنگ می‌کنه. تیم بک‌اند باید رفعش بکند. بعد از رفع سیستم سریع به حالت عادی برمی‌گرده. Disaster (فاجعه): یک اختلال گسترده و طولانی ‌مدته که کل سیستم یا کسب‌وکار را تهدید می‌کند و نیاز به طرح اضطرار (Disaster Recovery Plan) دارد. مثال: مرکز داده اصلی آتش گرفته و کل دیتابیس ۳ ساعت آفلاین شد. مجبور شدیم به منطقه دوم (DR Site) سوئیچ کنیم. پس فرقشون یکجورایی در دامنه و مدت زمان هست. . @elmedadeir

از صفحات اکسل تا امن نمودن سرویس‌های هوش مصنوعی سازمان - اولش فقط تحلیل داده بود. میومدیم اعداد رو نگاه میکردیم و دنبال این بودیم که بفهمیم چه خبر بوده. - بعد کمی گذشت و اعتماد بنفس پیدا کردیم. جلوتر رفتیم و رسیدیم به مدل‌سازی و پیش‌بینی آینده. دیگه نمی‌گفتیم «چه شد؟» گفتیم «چه خواهد شد؟» - ولی ناگهان گیر کردیم.  چون زیرساخت داده‌ی درست و حسابی نداشتیم. پس مجبور شدیم یک قدم عقب بریم. اینجا بود که «مهندســــی داده» وارد شد. لوله‌کشی داده، جابه‌جایی و ساختاردهی دیتا در مقیاس بزرگ و تلاش برای تحویل اطلاعاتِ تروتمیز به مصرف‌کنندگان تشنه‌ی دیتا. - مدتی که کارهای مهندسی داده رو بردیم جلو، فهمیدیم دستی و سنتی داریم کار می‌کنیم. این شد که دیتاآپس (DataOps) اومد؛ یعنی اتوماسیون، سی‌آی/سی‌دی برای داده، ورژن کنترل، تست خودکار و مانیتورینگ و در نهایت همکاری واقعی بین تیم‌ها. یعنی تقریبن همون دواپس، ولی اینبار برای داده. - حالا که دیتای خوب رسید دست اهلش، نوبت رسید به تمرکز روی مدل یادگیری ماشین. ضعف‌ها رو فهمیدیم. در این نقطه بود که ام‌ال‌آپس (MLOps) معرفی شد. یعنی مدل‌های یادگیری ماشین رو از نوت‌بوک دربیاریم و ببریم تو خط تولید. همون جوری که بچه‌های نرم‌افزار در جریان خلق یک محصول نرم‌افزاری استاندارهایی رو دارند، می‌بایست برای یک مدل یادگیری ماشین هم ما همین روش رو دنبال کنیم. - با اومدن مدل‌های زبانی بزرگ، ام‌ال‌آپس دیگه کافی نبود. هنوز ما استانداردهای بروزتری رو نیاز داشتیم. پس ال‌ال‌ام‌آپس (LLMOps) توسط توسعه دهندگان این نوع مدل‌ها پیشنهاد شد. مدیریت پرامپت، رگ (RAG)، هزینه‌های استنتاج. خلاصه همه چی در مرحله‌ی بکارگیری یک مدل زبانی بصورت سرویس در محیط پروداکشن باید در نظر گرفته بشود. - اما مدتی هست که عامل‌های خودمختار دارن همه کارها رو می‌گیرن دستشون، دیگه ال‌ال‌ام‌آپس هم یه جاهایی کم آورد. متخصصین ایجنت‌آپس (AgentOps) رو پیشنهاد دادند. یعنی مدیریت رفتار و تصمیم‌گیری این عامل‌ها. چون اگر درست محدود و هدایت نشوند، کل اکوسیستم سازمان رو ظرف چند ساعت به فنا خواهند داد. - و اما امروز؟ ام‌ال‌سک‌آپس (MLSecOps) و جن‌ای‌آی‌آپس (GenAIOps) اومدن بالای همه اینا؛ یعنی لایه‌‌ی امنیت و حکمرانی که تضمین می‌کنه هر چی تا الان ساختیم، واقعن قابل اعتماد باشه. من گمان می‌کنم خطرناک‌ترین شیوه‌ی چیدن تیم‌ها برای خلق یک محصول هوشمند اینه که ما به لایه‌ی آخر توجه نکنیم. چون اینجا اگر خوب عمل نکنیم، خفن‌ترین محصول هوشمند که براش شاید میلیاردها خرج شده، ظرف چند روز به چوخ برود. دوره‌ای که ما طراحی کردیم دقیقن همون مرحله‌ی نهمه؛ یعنی ام‌ال‌سک‌آپس. اونجا یاد می‌گیریم که چطور از کل این زنجیره در برابر حملات واقعی محافظت کنیم. نه تئوری، فقط کار عملی با ابزارهای روز. دقت کنید که من بشخصه یا هیچ فرد و سازمانی نمی‌تونیم از شما یک متخصص خفن امنیت مدل‌های یادگیری ماشین بسازیم. ما تنها سعی می‌کنیم که اون حالت ذهنی و طرز تفکر (mindset) فعلی شما رو بسمت امنیت هدایت کنیم. چطور؟ با نشون دادن چند مثال. آیا تمام حملات پوشش داده می‌شن؟ به هیچ وجه. چنین چیزی تنها یک ادعای احمقانه است. مابقی سئوالات شما، شاید در لینک زیر پاسخ داده شود https://www.m-fozouni.ir/mlsecops . #امنیت_سایبری #ام_ال_سک_آپس #یادگیری_ماشین #هوش_مصنوعی . @elmedadeir

این تصویر هم متن بالا رو خلاصه کرده. تروتمیز و مرتب . @elmedadeir

#باز_نشر یکی از اشتباه‌ترین سوال‌هایی که درباره Message Brokerها پرسیده میشه اینه: کافکا بهتره یا ربیت‌ام‌کیو؟ بنظرم سوال درست این نیست. سوال درست اینکه سیستم شما Command محوره یا Event محور؟ این تفاوت کوچیک، میتونه کل معماری سیستم را تغییر بده! فکر میکردم Message Broker فقط برای Async کردن Taskها استفاده میشه مثل ارسال Email، SMS یا ساخت PDF. فرض کنین یک سفارش ثبت میشه: اگر هدف فقط این باشد که یک Email یا SMS ارسال بشه، با یک Command طرف هستیم یعنی یک سرویس از سرویس دیگر میخواد که کاری را انجام بده. اما اگر بخوایم ثبت سفارش در اختیار Analytics، Recommendation، Fraud Detection، Search، Dashboard و حتی سرویس‌هایی که هنوز وجود ندارند قرار بگیره دیگه موضوع اجرای یک Task نیست موضوع انتشار یک Business Event است. اینجاست که تفاوت بین Queue و Event Log خودشو نشون میده😎. یکی از نکاتی که کمتر دربارش صحبت میشه اینکه Kafka صرفا یک Message Queue سریع‌تر نیست. کافکا بر پایه Append-Only Log طراحی شده یعنی Eventها برای مدتی مشخص (Retention Policy) نگهداری میشن و Consumerها با استفاده از Offset تصمیم میگیرن از کدام نقطه شروع به خواندن کنن. به همین دلیل اگر امروز یک Consumer جدید به سیستم اضافه بشه میتونن Eventهای گذشته را دوباره پردازش کن قابلیتی که در بسیاری از سناریوهای Analytics، Machine Learning و Event Replay اهمیت زیادی داره. از طرف دیگه، RabbitMQ برای پردازش Background Jobها طراحی شده جایی که قابلیت‌هایی مثل Routing، Retry، Dead Letter Queue (DLQ)، Priority Queue و مدیریت Workerها اهمیت بیشتری از نگهداری بلندمدت پیام‌ها دارن. نکته‌ای که برای من جالب بود در بسیاری از سیستم‌های بزرگ، Kafka و RabbitMQ رقیب هم نیستند مکمل هم هستند. الگوی رایجی که در معماری‌های Enterprise دیده میشه Kafka مسئول انتشار و توزیع Business Eventها هست و سرویس‌هایی که نیاز به اجرای Task دارن، اون Eventها را میگیرن و Jobهای خودشون از طریق RabbitMQ مدیریت کنن. شاید مهم‌ترین چیزی که از این مبحث یاد گرفتم انتخاب Message Broker نباید بر اساس محبوبیت ابزار باشه قبل از انتخاب هر تکنولوژی، باید به این سؤال جواب داد: ایا در حال انتقال یک Command هستیم یا انتشار یک Event؟ ✅ معمولا جواب همین سؤال، مسیر معماری را مشخص میکنه. ✍️ منبع: خانم مهندس زهرا سعادتی (توسعه دهنده‌ی بک‌اند) . @elmedadeir

This link appears safe now, but online threats evolve constantly. . @elmedadeir

یکی از دوستان در لینکدین به اشتراک گذاشته بودند. نمی‌دونم چکاری می‌کنند ولی ممکنه از جایی به بعد شخص گرفتار بشود. . @elmedadeir

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

وقتی وارد یک تیم جدید می‌شم، اولین چیزی که بررسی می‌کنم کیفیت کد نیست. قبل از اینکه حتی یک خط کد ببینم، دنبال جواب این سؤال‌ها می‌گردم: - ارتباط بین تیم محصول و تیم توسعه چطور تعریف شده؟ - آخرین Release چه زمانی بوده؟ - اگر امروز یکی از اعضای کلیدی در دسترس نباشه، چه اتفاقی می‌افته؟ - تیم برای انتشار نسخه به چند نفر وابسته است؟ - اگر یک باگ بحرانی در Production پیدا بشه، چند ساعت طول میکشه تا اصلاح و منتشر بشه؟ تجربه به من نشان داده که پاسخ این سؤال‌ها، بیشتر از هزار خط کد درباره بلوغ یک تیم حرف می‌زنه. شاید به همین دلیل است که امروز بیشتر از کیفیت کد، کیفیت فرآیندها و تصمیم‌های مهندسی توجهم رو جلب می‌کنه. . منبع: لینکدین میرحسین شایسته . @elmedadeir

رساندن مدل‌هایتان به مرحلهٔ تولید، چالش بنیادین یادگیری ماشین است. ام‌ال‌آپس یا Machine Learning Operations (MLOps) مجموعه‌ای از اصول آزموده ‌شده را ارائه می‌دهد که با هدف حل این مسئله به ‌شیوه‌ای قابل ‌اطمینان و خودکار طراحی شده‌اند. این راهنمای روشنگر شما را با چیستی MLOps (و تفاوت آن با DevOps) آشنا می‌کند و نشان می‌دهد که چگونه آن را در عمل به‌کار بگیرید تا مدل‌های یادگیری ماشین خود را عملیاتی کنید.

بخشی از مقدمه کتاب. . @elmedadeir

یکی از دوستان پستی منتشر کردند در خصوص اینکه «هوش مصنوعی داره قدرت تفکر رو از ماها می‌گیره و ...». همین‌جوری که می‌خوندم و با تکون‌ دادن سر تایید می‌کردم متن رو، وقتی به پاراگراف آخر رسیدم، متوجه شدم که پست توســـط هـــوش مصنــــوعی تولید شده، نشان بارزش هم کال تو اکشن بسیار ضایع و چند هشتگ داغون است (کال تو اکشن = یعنی از مخاطب بخواهیم یه چیزی اون زیر پست برامون بنویسه که الگوریتم‌ها ما رو آدم خفنی برچسب بزنند). و برای چند ثانیه مونده بودم چه عکس‌العملی (با کلاسش می‌شه ری‌اکشن 😎) نشون بدم، بخندم یا ناراحت بشم. باور کنید؛ اگر خودمون بنویسیم، در کوتاه‌ترین زمان ممکن نوشتــــــن رو یاد خواهیم گرفت. ما به آدمِ فنـــی‌نویس نیاز داریم. همه چیز رو نباید هوش مصنوعی برامون مستند کنه. یه چیزهایی باید از دست این پدرسوخــــته دور و محفوظ بمونه. واقعن چه بلایی داره سرمون میاد؟ . @elmedadeir

لینکدین «فرهاد زندشیراز»

چقدر جمله‌ی ساده ولی عمیقی بود 😎 . @elmedadeir

📦 استانداراد 0-1-1-2-3 برای بک‌آپ از دیتا: ========================= — 3 نسخه از دیتا باید داشته باشیم (1 اصلی + 2 پشتیبان). — 2 نوع مختلف رسانه ذخیره‌سازی (محل ذخیره‌سازی متفاوت) باید داشته باشیم. — 1 نسخه در مکان دیگر ذخیره شود (محیطی جداگانه). — ۱ نسخه آفلاین و غیر قابل تغییر باشد که نتوانند آنرا تغییر دهند (خرابکاری فایل‌های بک‌آپ توسط مریضان 🤓). — ۰ خطا در تست بک‌آپ، یعنی اگر این بک‌آپ‌ رو خواستیم ریستور کنیم هیچ خطایی نباید وجود داشته باشد. ========================= البته اگر این روش برای شما هزینه‌ی زیادی به بار میاره، میشه دو بند آخر رو حذف کرد که در واقع می‌رسیم به استاندارد 1-2-3 که مقداری قدیمی‌تر هست. نکته آخر: همین الان در بسیاری از سازمان‌ها چنین استانداری اجرا نمیشه. کار کاملن سنتی میره جلو (اصلن معلوم نیست بک‌آپ دارند یا ندارند)، چون هزینه نگهداری بک‌آپ رو ندارند؛ البته گمان می‌کنند که هزینه‌ی اضافی و چِرتی هست. تا روزی که همه چیز به چوخ برود. اون روز می‌شینند و میگن «کاشــــــــــــــــــــــــکی انجـــــــــــــــــام میـــــــــــــــــدادیم» 😉. منبع تصویر . @elmedadeir