نوشته های محمد حسین جلیلی

انواع دیتابیس‌ها در System Design

محمد حسین جلیلی — Tue, 30 Dec 2025 01:29:28 +0330

کِی از کدوم دیتابیس استفاده کنیم؟ (خیلی ساده و کاربردی)وقتی صحبت از طراحی سیستم می‌شود، یکی از اولین و مهم‌ترین تصمیم‌ها این است:داده‌ها را کجا و چطور ذخیره کنیم؟انتخاب اشتباه دیتابیس یعنی:سیستم کندهزینه‌ی بالامقیاس‌پذیری سختو در نهایت بازنویسی دردناکدر این بلاگ، قدم‌به‌قدم با نمونه‌های مختلف دیتابیس آشنا می‌شویم؛ نه با تعریف‌های دانشگاهی، بلکه با این سؤال کلیدی:«این دیتابیس دقیقاً به چه دردی می‌خورد و کِی باید سراغش بروم؟»دیتابیس‌های رابطه‌ای (Relational Databases)ایده‌ی اصلی چیست؟دیتابیس‌های رابطه‌ای داده‌ها را داخل جدول ذخیره می‌کنند.هر جدول:سطر دارد (رکورد)ستون دارد (فیلد)و یک شناسه‌ی یکتا (ID)جدول‌ها می‌توانند به هم وصل شوند؛ دقیقاً مثل اکسل، اما بسیار قوی‌تر.مثال ساده:جدول کاربرانجدول سفارش‌هاهر سفارش می‌داند متعلق به کدام کاربر است.چرا هنوز این‌قدر محبوب‌اند؟چون:ساختار مشخص دارندجلوی خراب شدن داده را می‌گیرندبرای داده‌های حساس فوق‌العاده‌انداین دیتابیس‌ها از چیزی به اسم تراکنش استفاده می‌کنند. یعنی:یا همه‌ی عملیات انجام می‌شود، یا هیچ‌کدام.این ویژگی برای پول، حساب، سفارش و پرداخت حیاتی است.کِی انتخاب درستی هستند؟اگر سیستم تو این ویژگی‌ها را دارد:داده‌ها ساختار مشخص دارندارتباط بین داده‌ها مهم استخطا در داده فاجعه استمثال‌های واقعی:سیستم‌های بانکیفروشگاه‌های آنلایننرم‌افزارهای سازمانی ( حقوق، انبار)جمع‌بندی سریعدیتابیس رابطه‌ای = نظم، امنیت، اعتماداگر شک داری، معمولاً شروع با دیتابیس رابطه‌ای انتخاب امن‌تری است. دیتابیس‌های Key-Value (کلید–مقدار)ایده‌ی اصلی چیست؟خیلی ساده:key → valueمثل یک دیکشنری بزرگ.مثال:"user:123" → { name: "Ali", theme: "dark" }نه جدول داریم، نه رابطه، نه پیچیدگی.چرا از این‌ها استفاده می‌کنیم؟چون:خیلی سریع‌اندبه‌راحتی مقیاس‌پذیر می‌شوندبرای داده‌های موقتی عالی‌اندولی حواست باشد:این دیتابیس‌ها برای تحلیل‌های پیچیده ساخته نشده‌اند.کِی انتخاب درستی هستند؟وقتی:فقط می‌خواهی چیزی را سریع ذخیره و سریع بخوانیرابطه‌ی بین داده‌ها مهم نیستسرعت از همه چیز مهم‌تر استمثال‌های واقعی:ذخیره‌ی session کاربرکش کردن اطلاعاتنگهداری توکن‌هاداده‌های لحظه‌ایجمع‌بندی سریعKey-Value = سرعت بالا، سادگی، مصرف کماگر دیتابیس رابطه‌ای مغز سیستم است، Key-Value حافظه‌ی کوتاه‌مدت آن است.دیتابیس‌های سندی (Document Databases)ایده‌ی اصلی چیست؟اینجا هر داده یک سند کامل است؛ معمولاً به شکل JSON.مثال:{ "name": "Laptop", "price": 1200, "features": ["SSD", "16GB RAM"], "reviews": [...] }هیچ اجباری نیست همه‌ی سندها دقیقاً شبیه هم باشند.چرا این انعطاف مهم است؟چون در خیلی از سیستم‌ها:داده‌ها دائم تغییر می‌کنندفیلدها اضافه یا حذف می‌شوندساختار ثابت ندارنددیتابیس‌های سندی این تغییرات را بدون دردسر می‌پذیرند.کِی انتخاب درستی هستند؟وقتی:داده‌ها نیمه‌ساختاریافته‌اندسرعت توسعه مهم‌تر از سخت‌گیری دیتابیس استمدل داده مرتب تغییر می‌کندمثال‌های واقعی:سیستم‌های محتوا (CMS)فروشگاه‌هایی با محصولات متنوعداده‌های IoTپروفایل کاربراندیتابیس‌های گرافی (Graph Databases)تا اینجا درباره‌ی جدول، کلید–مقدار و سند حرف زدیم.اما یک سؤال مهم:اگر خودِ «ارتباط» از خودِ داده مهم‌تر باشد چه؟اینجاست که دیتابیس‌های گرافی وارد بازی می‌شوند.ایده‌ی اصلی چیست؟در دیتابیس گرافی، داده‌ها به شکل نقشه‌ی ارتباطات ذخیره می‌شوند، نه جدول.سه مفهوم پایه داریم:Node (گره): موجودیت‌ها (مثل کاربر، محصول، مقاله)Edge (یال): رابطه‌ها (دوستِ، خریده، دنبال می‌کند)Property: اطلاعات اضافه روی گره یا رابطهمثال خیلی ساده:علی ← دوستِ → رضاعلی ← خریده → لپ‌تاپلپ‌تاپ ← متعلق به → برند Xاینجا «چه کسی به چه کسی وصل است» مهم‌تر از خود عددهاست.چرا دیتابیس‌های معمولی اینجا کم می‌آورند؟در دیتابیس رابطه‌ای:برای پیدا کردن ارتباط‌ها باید JOIN پشت JOIN بزنیهرچه ارتباط‌ها پیچیده‌تر شوند، کوئری‌ها کندتر و سخت‌تر می‌شونداما دیتابیس گرافی دقیقاً برای این سؤال ساخته شده:«از این نقطه، چطور به بقیه‌ی نقاط برسیم؟»کِی انتخاب درستی هستند؟وقتی:روابط چندلایه و تو در تو هستندتحلیل ارتباط‌ها مهم‌تر از ذخیره‌ی عدد و متن استسیستم باید سریع روی ارتباط‌ها حرکت کندمثال‌های واقعی و ملموسشبکه‌های اجتماعی (دوست، فالو، تعامل)سیستم‌های پیشنهاددهنده (این کاربر شبیه کیست؟)گراف دانش (ارتباط مفاهیم، اشخاص، محتوا)جمع‌بندی سریعGraph DB = قدرت تحلیل رابطه‌هااگر دیتابیس رابطه‌ای برای «داده» خوب است،دیتابیس گرافی برای «ارتباط» ساخته شده.نمونه‌ها:Neo4jAmazon Neptuneدیتابیس‌های Wide-Column (ستونیِ گسترده)اسمش ترسناک است، ولی ایده‌اش ساده‌تر از چیزی است که فکر می‌کنی.ایده‌ی اصلی چیست؟این دیتابیس‌ها شبیه جدول‌اند، اما:هر ردیف می‌تواند ستون‌های متفاوت داشته باشدستون‌ها می‌توانند خیلی زیاد باشندداده روی چندین سرور پخش می‌شودیعنی:مقیاس‌پذیری بالا، حتی با حجم عظیم دادهچرا ساخته شدند؟برای سیستم‌هایی که:داده خیلی زیاد می‌نویسندتوزیع‌شده‌اندباید همیشه در دسترس باشنداینجا سرعت نوشتن و تحمل خطا از «دقت لحظه‌ای» مهم‌تر است.محدودیت مهم (حواست باشد)JOIN پیچیده ندارندACID کامل ندارندبرای تراکنش‌های حساس مالی مناسب نیستندکِی انتخاب درستی هستند؟وقتی:لاگ، رویداد، کلیک، رفتار کاربر ذخیره می‌کنیداده‌ها پیوسته در حال اضافه شدن‌اندمقیاس خیلی بزرگ است (میلیون‌ها یا میلیاردها رکورد)مثال‌های واقعیآنالیتیکس وبمانیتورینگ سیستم‌هاداشبوردهای لحظه‌ایجمع‌بندی سریعWide-Column = حجم بالا + توزیع‌شده + سریعنمونه‌ها:Apache CassandraApache HBaseGoogle Bigtableدیتابیس‌های In-Memory (در حافظه)حالا برسیم به سریع‌ترین عضو این خانواده.ایده‌ی اصلی چیست؟به‌جای دیسک، داده مستقیماً داخل RAM نگه‌داری می‌شود.نتیجه؟سرعت بسیار بالاتأخیر بسیار کمپاسخ تقریباً آنیچرا این‌قدر سریع‌اند؟چون:دیسک حذف شدهI/O وجود نداردهمه‌چیز در حافظه استاما هیچ جادویی بدون هزینه نیست.محدودیت مهمRAM گران استحجمش محدود استاگر مراقب نباشی، داده از دست می‌رود (مگر با مکانیزم‌های پشتیبان)کِی انتخاب درستی هستند؟وقتی:سرعت از همه چیز مهم‌تر استداده موقتی یا نیمه‌موقتی استسیستم real-time می‌خواهیمثال‌های واقعیبازی‌های آنلاین (state بازی، session)معاملات لحظه‌ای مالیکش کردن داده‌های پرتکرارجمع‌بندی سریعIn-Memory = سرعت برق‌آسانه برای همه‌چیز،بلکه برای جاهایی که «کند بودن» غیرقابل قبول است.نمونه‌ها:RedisMemcachedیک نکته‌ی خیلی مهم (Blind Spot رایج)سیستم‌های واقعی معمولاً فقط یک دیتابیس ندارند.مثلاً:PostgreSQL برای داده‌های اصلیRedis برای کشCassandra برای لاگ‌هاGraph DB برای پیشنهاددهیاین یعنی:System Design = ترکیب هوشمندانه، نه تعصب روی یک ابزاردیتابیس‌های Time-Series (داده‌های زمانی)یک سؤال ساده اما کلیدی:اگر مهم‌ترین ویژگی داده، «زمان» باشد چه؟مثلاً:هر ثانیه CPU چقدر مصرف شده؟قیمت سهم در طول روز چطور تغییر کرده؟دمای سنسور هر ۵ ثانیه چقدر بوده؟اینجا با «داده‌ی معمولی» طرف نیستیم؛ با داده‌ی زمانی طرفیم.ایده‌ی اصلی چیست؟داده‌های Time-Series یعنی:یک مقدار + یک timestampمثال:(10:01:05) → CPU = 42% (10:01:10) → CPU = 47%این داده‌ها:پشت سر هم می‌آیندحجمشان زیاد استمعمولاً قدیمی‌ها کمتر استفاده می‌شونددیتابیس‌های معمولی با این الگو زود به زانو درمی‌آیند.TSDB چه کار متفاوتی می‌کند؟این دیتابیس‌ها برای زمان ساخته شده‌اند:نوشتن سریع پشت‌سرهمفشرده‌سازی هوشمندکوئری‌های مبتنی بر بازه‌ی زمانیحذف خودکار داده‌های قدیمی (Retention)کِی انتخاب درستی هستند؟وقتی:داده مرتب تولید می‌شود«روند» مهم‌تر از «رکورد تکی» استتحلیل در طول زمان داریمثال‌های واقعیمانیتورینگ سرورهاداده‌های IoT و سنسورهابازارهای مالیداشبوردهای performanceجمع‌بندی سریعTime-Series DB = استادِ داده‌های زمان‌داراگر دیتابیس رابطه‌ای برای «وضعیت فعلی» خوب است،TSDB برای «رفتار در طول زمان» ساخته شده.نمونه‌ها:InfluxDBTimescaleDBPrometheusدیتابیس‌های شی‌گرا (Object-Oriented Databases)حالا یک سناریوی آشنا برای برنامه‌نویس‌ها:اگر داده دقیقاً همان چیزی باشد که در کدت داری؟نه جدول،نه JSON،نه مپینگ.خودِ آبجکت.ایده‌ی اصلی چیست؟در دیتابیس شی‌گرا:داده = objectobject = instance از classهمراه با attribute و حتی behaviorیعنی همان چیزی که در Java، Python یا C++ می‌نویسی، مستقیم ذخیره می‌شود.چرا این ایده جذاب است؟چون:نیاز به ORM کم می‌شودتبدیل object ↔ table حذف می‌شودمدل‌های پیچیده راحت‌تر مدیریت می‌شونداما یک نکته‌ی مهم را نباید نادیده گرفت…واقعیت بازار (نکته‌ی مهم)این دیتابیس‌ها:رایج نیستنداکوسیستم کوچکی دارنددر مقیاس بزرگ کمتر استفاده می‌شوندبه همین دلیل، بیشتر خاص‌منظوره هستند.کِی انتخاب درستی هستند؟وقتی:مدل داده خیلی پیچیده استمنطق برنامه شدیداً شی‌گراستسادگی توسعه از همه چیز مهم‌تر استمثال‌های واقعیسیستم‌های شبیه‌سازیداده‌های چندرسانه‌ایاپلیکیشن‌های علمی یا تحقیقاتیجمع‌بندی سریعOODB = طبیعی برای OOP، خاص برای موارد محدودنمونه‌ها:ObjectDBdb4oدیتابیس‌های جستجوی متنی (Text Search Databases)سؤال:اگر کاربر بخواهد «جستجو» کند، نه فقط query ساده؟مثلاً:«لپ‌تاپ سبک برای برنامه‌نویسی»«خطاهای مربوط به timeout در لاگ‌ها»اینجا LIKE و WHERE کافی نیست.ایده‌ی اصلی چیست؟این دیتابیس‌ها برای:ایندکس‌کردن متنجستجوی سریعرتبه‌بندی نتایجساخته شده‌اند، نه برای ذخیره‌ی داده‌ی اصلی.چه قابلیت‌هایی دارند؟Full-Text Searchفازی سرچ (غلط املایی)Ranking نتایجفیلتر، highlight، aggregationکِی انتخاب درستی هستند؟وقتی:حجم متن زیاد استسرعت جستجو حیاتی استتجربه‌ی کاربر مهم استمثال‌های واقعیجستجوی محصولات فروشگاهموتورهای جستجوتحلیل و جستجوی لاگ‌هاجمع‌بندی سریعText Search DB = موتور جستجو، نه دیتابیس اصلیمعمولاً کنار دیتابیس اصلی می‌آید، نه به‌جای آن.نمونه‌ها:ElasticsearchApache SolrSphinxنکته‌ی استراتژیک (جایی که خیلی‌ها اشتباه می‌کنند)TSDB برای گزارش و مانیتورینگSearch DB برای جستجوDB اصلی برای داده‌ی مرجعدیتابیس‌های مکانی (Spatial Databases)یک سؤال ساده:اگر «مکان» جزو داده‌ی اصلی باشد چه؟نه فقط اسم شهر یا کشور،بلکه:فاصلهمسیرمحدودههم‌پوشانیاینجا دیتابیس معمولی جواب نمی‌دهد.ایده‌ی اصلی چیست؟دیتابیس‌های مکانی برای ذخیره و تحلیل داده‌های جغرافیایی ساخته شده‌اند.این داده‌ها می‌توانند باشند:نقطه (Point) → مثل موقعیت کاربرخط (Line) → مثل مسیر حرکتچندضلعی (Polygon) → مثل محدوده‌ی یک شهرو مهم‌تر از خود داده:«رابطه‌ی مکانی بین آن‌ها»چرا دیتابیس معمولی کم می‌آورد؟سؤالات مکانی از این جنس‌اند:نزدیک‌ترین رستوران به من کدام است؟این مسیر از کدام مناطق عبور می‌کند؟این دو محدوده هم‌پوشانی دارند یا نه؟برای این‌ها، دیتابیس‌های مکانی از ایندکس‌های مخصوص (مثل R-tree) استفاده می‌کنند تا کوئری‌ها سریع باشند.کِی انتخاب درستی هستند؟وقتی:مکان و فاصله مهم استکاربر location داردتحلیل جغرافیایی انجام می‌دهیمثال‌های واقعینقشه‌ها و مسیریابیسرویس‌های location-basedلجستیک و حمل‌ونقلردیابی خودرو و ناوگانجمع‌بندی سریعSpatial DB = داده + مکان + تحلیل جغرافیاییاغلب به‌صورت افزونه روی دیتابیس‌های دیگر استفاده می‌شوند، نه به‌تنهایی.نمونه‌ها:PostGISOracle SpatialBlob Datastore (ذخیره‌سازی فایل‌های حجیم)حالا یک اشتباه رایج:ذخیره‌ی فایل داخل دیتابیس رابطه‌ای.اگر این کار را می‌کنی، احتمالاً داری اشتباه می‌روی.ایده‌ی اصلی چیست؟Blob Datastore برای نگهداری:تصویرویدیوصدافایلبکاپساخته شده، نه برای جدول و رکورد.اینجا داده:ساختار نداردبزرگ استزیاد دانلود می‌شودچرا دیتابیس معمولی مناسب نیست؟چون:حجم فایل‌ها بالاستBackup سخت می‌شودPerformance می‌ریزدهزینه بالا می‌رودBlob Storage دقیقاً برای همین سناریو بهینه شده است.کِی انتخاب درستی هستند؟وقتی:فایل زیاد داریدسترسی global می‌خواهیdurability و scalability مهم استمثال‌های واقعیذخیره‌ی تصاویر اپلیکیشنویدیو استریملاگ‌های حجیمبکاپ و آرشیوجمع‌بندی سریعBlob Storage = فایل‌ها بیرون، دیتا داخل دیتابیساین دو را قاطی نکن.نمونه‌ها:Amazon S3Azure Blob StorageHDFSدیتابیس‌های Ledger (دفترکل / تغییرناپذیر)اینجا با یک مفهوم جدی طرفیم:داده‌ای که نباید تغییر کند. حتی توسط ادمین.ایده‌ی اصلی چیست؟Ledger Database یعنی:فقط اضافه می‌کنیحذف و ویرایش وجود نداردهمه‌چیز تاریخچه داردتغییر قابل اثبات استاین شبیه بلاک‌چین است، ولی الزاماً عمومی یا رمزنگاری‌شده مثل کریپتو نیست.چرا مهم‌اند؟چون در بعضی سیستم‌ها:اعتماد حیاتی استدستکاری فاجعه استردپا باید بماندکِی انتخاب درستی هستند؟وقتی:شفافیت مهم استaudit trail می‌خواهیداده حقوقی یا حساس استمثال‌های واقعیزنجیره تأمینسوابق پزشکیسیستم رأی‌گیریقراردادهاجمع‌بندی سریعLedger DB = حقیقتی که قابل پاک شدن نیستنمونه‌ها:Amazon QLDBHyperledger Fabricدیتابیس‌های سلسله‌مراتبی (Hierarchical Databases)و حالا یک مدل قدیمی، اما هنوز مهم برای فهم.ایده‌ی اصلی چیست؟داده‌ها به شکل درخت ذخیره می‌شوند:هر نود یک والد داردمی‌تواند چند فرزند داشته باشدرابطه فقط یک‌طرفه استمثل:پوشه‌هاساختار سازمانیچرا امروز کمتر استفاده می‌شوند؟چون:انعطاف کمی دارندتغییر ساختار سخت استروابط پیچیده را خوب هندل نمی‌کنندبه همین دلیل، دیتابیس‌های رابطه‌ای و NoSQL جای آن‌ها را گرفته‌اند.کِی هنوز کاربرد دارند؟وقتی:ساختار واقعاً درختی استرابطه‌ها ساده و ثابت‌اندتغییر کم استمثال‌های واقعیساختار فایل سیستمچارت سازمانیتنظیمات سیستمیجمع‌بندی سریعHierarchical DB = ساده، قدیمی، محدودبیشتر برای فهم مدل داده مهم‌اند تا انتخاب در پروژه‌های جدید.نمونه‌ها:IBM IMSWindows Registryدیتابیس‌های برداری (Vector Databases)یک سؤال خیلی مهم در دنیای امروز:اگر داده «شبیه» باشد، نه «برابر» چه؟مثلاً:این متن شبیه کدام متن‌هاست؟این تصویر به کدام تصاویر نزدیک‌تر است؟سلیقه‌ی این کاربر به کدام کاربران می‌خورد؟اینجا = و WHERE کاملاً بی‌مصرف‌اند.ایده‌ی اصلی چیست؟در دیتابیس‌های برداری:هر داده به یک بردار عددی تبدیل می‌شوداین بردارها در فضای چندبُعدی قرار می‌گیرندجستجو بر اساس شباهت انجام می‌شود، نه تطابق دقیقمثال ذهنی:متن، تصویر یا صدا → تبدیل به لیست عددسپس: «نزدیک‌ترین‌ها» پیدا می‌شوندچرا این دیتابیس‌ها ناگهان مهم شدند؟به‌خاطر AI.مدل‌های یادگیری ماشین:متن را embedding می‌کنندتصویر را embedding می‌کنندرفتار کاربر را embedding می‌کنندو این embeddingها بدون دیتابیس برداری عملاً بلااستفاده‌اند.کِی انتخاب درستی هستند؟وقتی:جستجوی معنایی می‌خواهیrecommendation هوشمند داریبا AI، NLP یا vision کار می‌کنیمثال‌های واقعیجستجوی تصویری (شبیه این عکس)پیشنهاد محتواتشخیص ناهنجاریsearch هوشمند (semantic search)جمع‌بندی سریعVector DB = قلب سیستم‌های AI-محوراین دیتابیس‌ها معمولاً کنار دیتابیس اصلی می‌آیند، نه به‌جای آن.نمونه‌ها:FaissMilvusPineconeدیتابیس‌های Embedded (توکار)حالا بیاییم برگردیم به ساده‌ترین، اما بسیار کاربردی‌ترین نوع دیتابیس.ایده‌ی اصلی چیست؟Embedded Database:سرور جدا نداردداخل خود اپلیکیشن اجرا می‌شودنصب و راه‌اندازی نمی‌خواهدیعنی:دیتابیس = بخشی از برنامهچرا این مهم است؟چون خیلی وقت‌ها:سیستم کوچک استیک کاربر داردمنابع محدودندسادگی مهم‌تر از مقیاس استراه‌اندازی PostgreSQL یا MongoDB برای این سناریوها زیاده‌روی است.کِی انتخاب درستی هستند؟وقتی:اپلیکیشن لوکال استgame یا desktop app داریداده پیچیده یا خیلی حجیم نیستمثال‌های واقعیذخیره‌ی progress بازیتنظیمات نرم‌افزارداده‌های آفلاین موبایل یا دسکتاپجمع‌بندی سریعEmbedded DB = سادگی، سرعت، بدون دردسرنمونه‌ها:SQLiteRocksDBBerkeley DBجمع‌بندی نهایی (نکته‌ی استراتژیک)اگر تا اینجا یک چیز باید یادت مانده باشد، این است:هیچ دیتابیسی برای همه‌چیز ساخته نشده.انتخاب دیتابیس یعنی پاسخ دادن به این سؤال‌ها:داده‌ام چه شکلی است؟سرعت مهم‌تر است یا دقت؟رابطه مهم است یا شباهت؟مقیاس چقدر است؟هزینه چقدر مهم است؟سیستم‌های حرفه‌ای:ترکیبی‌اندماژولارندتعصب ندارنداگر بخواهم این بلاگ را یک جمله جمع کنم:System Design یعنی انتخاب آگاهانه، نه استفاده‌ی کورکورانه از ابزار محبوب.سخن پایانیدر طراحی سیستم‌های نرم‌افزاری، انتخاب دیتابیس یک تصمیم صرفاً فنی یا سلیقه‌ای نیست؛ این انتخاب مستقیماً بر مقیاس‌پذیری، پایداری، هزینه و حتی آیندهٔ محصول اثر می‌گذارد. هر نوع دیتابیس—از رابطه‌ای و سندی گرفته تا گراف، زمانی، مکانی و برداری—برای حل مسئله‌ای خاص طراحی شده است و استفادهٔ نادرست از آن‌ها، معمولاً در مقیاس یا زمان رشد سیستم خودش را به شکل بحران نشان می‌دهد.آنچه در System Design اهمیت دارد، نه دانستن نام ابزارها، بلکه درک عمیق الگوهای داده، رفتار سیستم تحت بار، و ترکیب هوشمندانهٔ چند فناوری در کنار یکدیگر است. سیستم‌های واقعی معمولاً با یک دیتابیس ساخته نمی‌شوند، بلکه با معماری درست به تعادل می‌رسند.اگر در حال طراحی یا توسعهٔ سامانه‌های نرم‌افزاری مقیاس‌پذیر، سیستم‌های داده‌محور، یا محصولات مبتنی بر real-time، analytics یا AI هستید، تیم معماری و توسعهٔ نرم‌افزار شرکت راهکار نگار هوشمند (آرکان) می‌تواند از تحلیل مسئله و انتخاب معماری مناسب، تا طراحی زیرساخت داده و پیاده‌سازی عملیاتی، همراه شما باشد.این مقاله با هدف انتقال تجربه و ارتقای نگاه معماری در انتخاب دیتابیس‌ها، توسط تیم توسعهٔ نرم‌افزار شرکت راهکار نگار هوشمند (آرکان) تهیه شده است.#System_Design#Database_Architecture#Software_Architecture#Backend_Engineering#Distributed_Systems#Scalable_Systems#Data_Engineering#NoSQL#AI_Systems#RealTime_Systems#شرکت_راهکار_نگار_هوشمند#arcanco

طراحی مکانیزم امتیازدهی بازی با Redis (Scoring)

محمد حسین جلیلی — Sat, 20 Dec 2025 12:57:03 +0330

قبل از هر چیز یک اعتراف صادقانه:این سناریو لزوماً از دل یک بازی واقعی نیامده. بیشتر یک مدل ذهنی است برای این‌که بفهمیم Redis چطور فکر می‌کند و چطور می‌شود از آن برای ساخت مکانیزم‌های بازی استفاده کرد.فرض کنیم یک بازی داریم به اسم Super Redis Brothers؛یک بازی پلتفرمر آنلاین که به یک سرور مرکزی وصل است. شخصیت اصلی بازی، Redisman، باید سکه جمع کند، با سکه‌ها power-up بگیرد و زنده بماند.تمرکز ما در این مقاله فقط روی امتیازدهی (جمع‌کردن سکه) است.ساده‌ترین حالت: شمارنده با Stringاگر فقط بخواهیم تعداد سکه‌های یک بازیکن را نگه داریم، ساده‌ترین راه استفاده از یک counter است.مثلاً:INCR pID123یا اگر چند سکه با هم جمع شود:INCRBY pID123 10کم‌کردن امتیاز هم با:DECRBY pID123 5این روش:سریع است (O(1))ساده استولی به‌شدت محدودمشکل کجاست؟به محض این‌که بخواهی:لیدربورد بسازیبازیکن‌ها را با هم مقایسه کنیرتبه بدهیدیگر string جواب نمی‌دهد.چرا Sorted Set انتخاب بهتری است؟اینجاست که Sorted Set وارد بازی می‌شود.ایده خیلی ساده است:یک کلید داریم برای همه‌ی امتیازهاmember = شناسه‌ی بازیکنscore = تعداد سکه‌هابا این مدل:هم امتیاز هر بازیکن را داریهم می‌توانی رتبه‌بندی بگیریهم لیدربورد بسازیمدل‌سازی جمع‌کردن سکه با Sorted Setفرض کنیم همه‌ی امتیازها زیر این کلید ذخیره می‌شوند:scoresوقتی بازیکن سکه جمع می‌کند:ZINCRBY scores 10 pID1234چند نکته‌ی مهم اینجا وجود دارد:اگر بازیکن قبلاً وجود نداشته باشد، Redis از صفر شروع می‌کندscore صفر یک مقدار معتبر استscore منفی هم مجاز است (که بعداً به دردسرش می‌خوریم!)پیچیدگی این عملیات:O(log n)برای بازی و آپدیت‌های پرتعداد کاملاً قابل قبولنمایش سکه‌ها در HUD بازیبرای نمایش تعداد سکه‌ها روی صفحه‌ی بازی، فقط کافی است امتیاز فعلی را بگیریم:ZSCORE scores pID1234نکته‌ی جالب:ZINCRBY خودش امتیاز جدید را برمی‌گرداندیعنی همان پاسخ Redis می‌تواند مستقیم وارد HUD شودبدون کوئری اضافهخرج‌کردن سکه‌ها (Power-Up)فرض کنیم یک power-up داریم که:۱۰ سکه می‌گیرددشمن‌ها را فریز می‌کنداز نظر Redis:ZINCRBY scores -10 pID1234کاملاً منطقی.یا اگر بخواهیم سکه‌ها را صفر کنیم (مثل Sonic وقتی ضربه می‌خورد):ZADD scores 0 pID1234اینجا شاید ZADD عجیب به نظر برسد،ولی در واقع یک upsert است:اگر عضو باشد → امتیازش آپدیت می‌شوداگر نباشد → با امتیاز صفر اضافه می‌شودمشکل واقعی: امتیاز منفی!اینجا به یک ساده‌سازی خطرناک می‌رسیم.اگر Redisman صفر سکه داشته باشد و power-up بخورد:ZINCRBY scores -10 pID1234نتیجه:-10که احتمالاً در منطق بازی غلط است.پس قبل از کم‌کردن امتیاز، باید چک کنیم:آیا بازیکن به‌اندازه‌ی کافی سکه دارد یا نه؟حل مسئله با Lua Script (اتمیک و تمیز)منطق به زبان ساده:امتیاز فعلی را بگیراگر کافی بود، کم کناگر نه، هیچ کاری نکنبه‌صورت شبه‌کد:if currentScore >= neededCoins: decrementدر Redis، بهترین جا برای این منطق یک Lua Script است؛چون:اتمیک اجرا می‌شودبین ZSCORE و ZINCRBY هیچ عملیات دیگری نمی‌پرداسکریپت نمونه:EVAL " if tonumber(redis.call('zscore',KEYS[1],ARGV[2])) >= (ARGV[1]*-1) then return tonumber(redis.call('zincrby',KEYS[1],ARGV[1],ARGV[2])) end " 1 scores -10 pID1234این اسکریپت:اول امتیاز را می‌گیردچک می‌کند به زیر صفر نرودفقط در صورت مجاز بودن، امتیاز را کم می‌کنددر محیط production:معمولاً از SCRIPT LOAD و EVALSHA استفاده می‌شودولی منطق دقیقاً همین استساخت لیدربورد با Sorted Setاگر تا این‌جا همراه بوده باشی، حالا یک نکته باید کاملاً روشن باشد:Sorted Set تقریباً برای لیدربورد ساخته شده است.ما همین حالا هم امتیاز هر بازیکن را به‌عنوان score داخل یک Sorted Set نگه می‌داریم.پس بخش بزرگی از منطق لیدربورد از قبل آماده است.نمایش نفرات برتر (Top-N)در بیشتر بازی‌ها، لیدربورد از بیشترین امتیاز به کمترین نمایش داده می‌شود.برای همین از ZREVRANGE استفاده می‌کنیم.ZREVRANGE scores 0 9 WITHSCORESاین دستور:۱۰ بازیکن اول را برمی‌گرداندبالاترین امتیاز در ابتدای لیست استامتیازها هم همراه اسم بازیکن‌ها برمی‌گرددنکته‌ی مهم:Redis تساوی امتیازها را هم درست مدیریت می‌کندممکن است ۱۰ نفر اول، همگی امتیاز یکسان داشته باشندترتیب همچنان پایدار و قابل پیش‌بینی استلیدربورد «اطراف من» (نه فقط Top 10)نمایش ۱۰ نفر اول برای همه مفید نیست.اگر کاربر تازه‌وارد باشد و رتبه‌اش مثلاً ۴۸٬۳۲۱ باشد،دیدن Top 10 هیچ انگیزه‌ای ایجاد نمی‌کند.آنچه کاربر واقعاً می‌خواهد ببیند:چند نفر بالاتر از خودشچند نفر پایین‌تر از خودشگرفتن رتبه‌ی کاربراول باید بفهمیم بازیکن چندم است:ZREVRANK scores pID1234این دستور:رتبه‌ی بازیکن را از بالا برمی‌گردانددقیقاً همان چیزی که برای لیدربورد لازم داریمنمایش بازه‌ای اطراف کاربرحالا که رتبه را داریم، می‌توانیم مثلاً:۵ نفر بالاترخود کاربر۵ نفر پایین‌تررا با یک ZREVRANGE بگیریم.ایده ساده است:start = rank - 5 end = rank + 5و بعد:ZREVRANGE scores start end WITHSCORESاین مدل لیدربورد:بسیار شخصی‌تر استانگیزه‌ی رقابت ایجاد می‌کنددر بازی‌های واقعی بسیار مؤثرتر از Top-N استاما یک مشکل جدی در مقیاس بالاتا این‌جا همه‌چیز عالی به نظر می‌رسد،اما این مدل یک نقطه‌ی ضعف معماری دارد.در تمام مثال‌ها، ما فقط با یک کلید کار می‌کنیم:scoresدر مقیاس کوچک مشکلی نیست.اما در یک بازی واقعی با ترافیک بالا چه اتفاقی می‌افتد؟مشکل Hot Keyدر Redis (به‌خصوص در حالت cluster):هر کلید روی یک shard مشخص قرار می‌گیردتمام عملیات روی آن کلید، روی همان نود انجام می‌شودنتیجه:همه‌ی ZINCRBYهمه‌ی ZREVRANGEهمه‌ی ZREVRANKروی یک ماشین می‌افتد.حتی اگر:ده‌ها shardیا چندین نود داشته باشیتا وقتی کلید یکی است،گلوگاه همان یک shard خواهد بود.به این حالت می‌گویند: Hot Keyدر یک بازی با:جمع‌کردن سکه‌ی زیادخرج‌کردن power-upکاربران هم‌زمان زیاداین محدودیت واقعاً خودش را نشان می‌دهد.راه‌حل ساده؟ نه کاملاًیک راه این است که:امتیاز هر بازیکن را در یک key جداگانه با INCR نگه داریمهر چند وقت یک‌بار با SCAN، یک Sorted Set بسازیماما این کار:real-time بودن لیدربورد را از بین می‌بردسیستم‌های جانبی و cron job می‌خواهدپیچیدگی را بالا می‌بردیعنی مشکل را حل نمی‌کند، فقط جابجا می‌کند.یک راه‌حل مقیاس‌پذیرتر (ولی خاص)در معماری‌های پیشرفته‌تر، می‌شود از Redis به‌صورت توزیع‌شده‌تر استفاده کرد.مثلاً در Redis Enterprise Active-Active:چند کلاستر هم‌رده داریمنوشتن‌ها بین آن‌ها پخش می‌شودداده‌ها بعداً با مدل CRDT همگام می‌شونددر این حالت:فشار نوشتن روی یک کلید تقسیم می‌شودبرای workloadهای bursty (افزایش ناگهانی ترافیک) مناسب‌تر استreal-time کامل نیست، ولی بسیار مقیاس‌پذیرتر استاین راه‌حل:عمومی نیستبرای همه پروژه‌ها هم لازم نیستولی دانستنش برای طراحی سیستم‌های بزرگ حیاتی استسخن پایانیدر بازی‌ها و سامانه‌های بلادرنگ، امتیازدهی و رتبه‌بندی فقط یک قابلیت ظاهری نیست؛ بخشی از هستهٔ طراحی سیستم است. Redis و به‌ویژه Sorted Set امکان پیاده‌سازی سریع و کارآمد مکانیزم‌هایی مثل امتیازدهی، لیدربورد و رتبهٔ شخصی کاربران را فراهم می‌کنند، اما در مقیاس بالا، تصمیم‌های معماری—مانند مدیریت hot key و الگوی توزیع داده—نقش تعیین‌کننده‌ای در پایداری سامانه دارند.اگر در حال طراحی یا توسعهٔ بازی‌ها و سیستم‌های real-time با بار بالا هستید، تیم معماری و توسعهٔ نرم‌افزار شرکت راهکار نگار هوشمند (آرکان) می‌تواند از تحلیل مسئله تا طراحی معماری مقیاس‌پذیر و پیاده‌سازی عملیاتی، همراه شما باشد.این مقاله با هدف انتقال تجربه و آگاهی‌بخشی فنی، توسط تیم توسعهٔ نرم‌افزار شرکت راهکار نگار هوشمند (آرکان) تهیه شده است.#Redis#SortedSet#Leaderboard#Game_Mechanics#RealTime_Systems#Scalable_Architecture#Backend_Engineering#System_Design#High_Performance#Distributed_Systems#Software_Architecture#شرکت_راهکار_نگار_هوشمند#arcanco

طراحی لیدربورد و سیستم‌های رتبه‌بندی با Redis Sorted Set

محمد حسین جلیلی — Sat, 20 Dec 2025 12:22:57 +0330

برای این‌که Sorted Set را درست بفهمیم، لازم است خیلی خلاصه بدانیم Set و Hash در Redis چه کاری می‌کنند؛ چون ZSET عملاً از دل همین دو مفهوم بیرون آمده.Redis Set چیست؟Set در Redis یک مجموعه از رشته‌های یکتاست.هر عضو فقط یک‌بار می‌تواند وجود داشته باشدترتیب نداردفقط می‌توانی بپرسی «هست یا نیست؟»Set برای سناریوهایی خوب است که:تکراری بودن مهم نیستفقط عضویت مهم است، نه مقدار یا رتبهمثلاً:لیست کاربران آنلاینلیست آی‌دی‌هایی که قبلاً کاری را انجام داده‌انداما همین‌جا محدودیتش معلوم می‌شود:نه ترتیبی دارد، نه عددی، نه مفهومی از رتبه.مثال Set: فقط «هست یا نیست»فرض کن می‌خوای بفهمی کدوم کاربرها الان آنلاین‌اند.ذهنی که پشت داده استما فقط اینو می‌خوای:user_42 آنلاین هست یا نه؟user_99 آنلاین هست یا نه؟هیچ امتیاز، ترتیب یا اطلاعات اضافه‌ای مهم نیست.داده در Redis چطور ذخیره می‌شودSADD online_users user_42 SADD online_users user_99 SADD online_users user_7تو چطور می‌بینیشSMEMBERS online_usersخروجی:user_7 user_42 user_99نکته مهم:ترتیب هیچ معنایی ندارد. Redis عمداً ترتیب را به تو تضمین نمی‌دهد.اگر بپرسی:SISMEMBER online_users user_42خیلی سریع جواب می‌گیری: بله یا خیر.Redis Hash چیست؟Hash شبیه یک دیکشنری یا آبجکت است:یک کلید اصلی داریداخلش مجموعه‌ای از field → value نگه می‌داریHash برای این عالی است که:اطلاعات مرتبط یک موجودیت را کنار هم نگه داریبه هر فیلد جداگانه دسترسی داشته باشیمثلاً:پروفایل کاربر (name، level، xp، status)تنظیمات یک بازی یا سرویساما Hash هم یک ضعف جدی دارد:هیچ مفهومی از مرتب‌سازی بین چند عضو مختلف ندارد.مثال Hash: یک موجودیت با چند ویژگیحالا فرض کن می‌خوای پروفایل یک کاربر را ذخیره کنی.ذهنی که پشت داده استما یک کاربر داریم با چند ویژگی:ناملولامتیاز کلیهمه این‌ها به یک موجودیت تعلق دارند.داده در Redis چطور ذخیره می‌شودHSET user:42 name "Ali" level 7 totalScore 1850تو چطور می‌بینیشHGETALL user:42خروجی:name Ali level 7 totalScore 1850یا اگر فقط یکی از فیلدها مهم باشد:HGET user:42 levelاینجا Hash عالی است،اما هیچ راهی نداری بگویی:«کدام کاربر امتیازش بالاتر است؟»حالا چرا Sorted Set به‌وجود آمده؟اینجا Redis می‌گوید:از Set، یکتایی اعضا را بگیراز Hash، نگاشت عضو به مقدار را بگیرو یک چیز اضافه کن که هیچ‌کدام ندارند: ترتیب دائمینتیجه می‌شود Sorted Set:هر عضو یکتا است (مثل Set)هر عضو یک عدد دارد (مثل Hash)و کل مجموعه همیشه مرتب استنکته‌ای که معمولاً نادیده گرفته می‌شوداگر جایی داری:Set + سورت در کدیا Hash + مرتب‌سازی دستیدر واقع داری کاری می‌کنی که Redis از قبل برایش ساخته شده، ولی استفاده‌اش نمی‌کنی.این نه بهینه است، نه مقیاس‌پذیر، و نه تمیز.مثال Sorted Set: رتبه‌بندی واقعیحالا می‌رسیم به لیدربورد.ذهنی که پشت داده استما می‌خواهیم:هر کاربر یک امتیاز داشته باشدبتوانیم بفهمیم چه کسی بالاتر استسریع ۱۰ نفر اول را ببینیمداده در Redis چطور ذخیره می‌شودZADD leaderboard 1850 user_42 ZADD leaderboard 2100 user_7 ZADD leaderboard 1600 user_99اینجا:score = امتیازmember = شناسه‌ی کاربرتو چطور می‌بینیش۱۰ نفر اول:ZREVRANGE leaderboard 0 9 WITHSCORESخروجی:user_7 2100 user_42 1850 user_99 1600Redis بدون این‌که ازش بخواهی سورت کند،از اول داده را مرتب نگه داشته.مثال امتیاز مساوی (جایی که خیلی‌ها اشتباه می‌کنند)فرض کن دو نفر امتیاز برابر دارند:ZADD leaderboard 2000 user_20 ZADD leaderboard 2000 user_3Redis چه کار می‌کند؟چون score برابر است، می‌رود سراغ اسم‌ها.از نظر لغوی:user_20 > user_3پس ترتیب همیشه ثابت است و لیدربورد «به هم نمیریزد».تعریف سادهیک Redis Sorted Set مجموعه‌ای از رشته‌های یکتا (members) است که هر کدام یک امتیاز عددی (score) دارند و همیشه به‌صورت مرتب‌شده نگه‌داری می‌شوند.نکته‌ی کلیدی اینجاست:مرتب‌بودن، ویژگی ذاتی داده است، نه نتیجه‌ی کوئری.یعنی Redis از لحظه‌ی ذخیره‌سازی، ترتیب را حفظ می‌کند؛ نه این‌که هر بار موقع خواندن، سورت کند.Sorted Set دقیقاً چه مشکلی را حل می‌کند؟1. لیدربورد (Leaderboard)واضح‌ترین و مهم‌ترین کاربرد.امتیاز هر کاربر = scoreشناسه‌ی کاربر = memberگرفتن ۱۰ نفر اول؟ → O(log N)آپدیت امتیاز؟ → O(log N)برای یک بازی آنلاین با میلیون‌ها کاربر، این یعنی نجات پروژه.2. Rate Limiting (محدودسازی درخواست)با ZSET می‌توانی Sliding Window Rate Limiter بسازی:هر درخواست = یک timestamp به‌عنوان scoreحذف درخواست‌های قدیمیشمردن درخواست‌های بازه‌ی زمانیبدون نیاز به دیتابیس سنگین یا لاک پیچیده.Sorted Set ترکیب کدام ساختارهاست؟می‌تونی Sorted Set رو این‌طوری تصور کنی:از Set:اعضا یکتا هستندهیچ عضوی تکراری نیستاز Hash:هر عضو به یک مقدار (score) مپ شدهاما چیزی که هیچ‌کدام ندارند:مرتب‌سازی دائمی و ذاتیقانون مرتب‌سازی در Sorted SetRedis برای مرتب‌سازی دو قانون خیلی شفاف دارد:قانون اول: امتیاز (Score)اگر دو عضو score متفاوت داشته باشند:A > B اگر A.score > B.scoreیعنی امتیاز بالاتر = رتبه بالاتر.قانون دوم: ترتیب لغوی (Lexicographical)اگر دو عضو امتیاز یکسان داشته باشند:A > B اگر A.member از نظر لغوی بزرگ‌تر از B.member باشدمثلاً:score = 100 "user_20" > "user_3"نکته مهم:چون اعضا یکتا هستند، دو رشته‌ی کاملاً یکسان وجود ندارداین قانون باعث می‌شود ترتیب همیشه deterministic باشدچرا این جزئیات مهم‌اند؟چون در سیستم واقعی:امتیازها مساوی می‌شوندهزاران کاربر score برابر دارنداگر ترتیب مشخص نباشد، UI شما «به هم میریزه»کاربر حس بی‌عدالتی می‌گیردRedis این مشکل را در سطح ساختار دیتا حل کرده، نه در کد شما.یک مثال ساده: امتیازدهی به راننده‌ها با Redis Sorted Setبیایم همه‌چیز رو با یک مثال خیلی ساده شروع کنیم:فرض کن چند راننده داریم و هرکدوم توی اولین مسابقه یک امتیاز گرفته‌اند.هدف ما اینه که این امتیازها رو ذخیره کنیم و هر لحظه بتونیم رتبه‌بندی‌شون رو ببینیم.اضافه‌کردن داده‌ها به Sorted Setبرای این کار از دستور ZADD استفاده می‌کنیم.ZADD racer_scores 10 "Norem" ZADD racer_scores 12 "Castilla" ZADD racer_scores 8 "Sam-Bodden" 10 "Royce" 6 "Ford" 14 "Prickett"چند نکته‌ی خیلی مهم همین‌جا وجود دارد که معمولاً نادیده گرفته می‌شود:ZADD شبیه SADD است، اما قبل از هر عضو یک score می‌گیرداین دستور variadic است؛ یعنی می‌توانی چند score–member را یک‌جا اضافه کنیمقدار برگشتی نشان می‌دهد چند عضو جدید اضافه شده‌اند (نه این‌که چند تا دستور اجرا شده)از همین لحظه، Redis داده‌ها را مرتب‌شده نگه می‌دارد.دیدن لیست مرتب‌شده‌ی راننده‌هاحالا بدون هیچ سورت اضافه‌ای، می‌توانیم لیست را بگیریم.ZRANGE racer_scores 0 -1خروجی:Ford Sam-Bodden Norem Royce Castilla Prickettاین خروجی از کمترین امتیاز به بیشترین است.چرا؟ چون ZRANGE همیشه از پایین به بالا می‌آید.اگر برعکسش را بخواهی:ZREVRANGE racer_scores 0 -1خروجی:Prickett Castilla Royce Norem Sam-Bodden Fordاینجا بالاترین امتیاز اول می‌آید، دقیقاً چیزی که برای لیدربورد لازم داریم.نکته‌ی ظریف:0 یعنی اولین عنصر-1 یعنی آخرین عنصردقیقاً مثل LRANGE در لیست‌ها.دیدن امتیازها همراه با اسم‌هاتا این‌جا فقط اسم‌ها را دیدیم. اگر امتیاز هم بخواهیم:ZRANGE racer_scores 0 -1 WITHSCORESخروجی به‌صورت جفت‌های پشت‌سرهم برمی‌گردد:Ford 6 Sam-Bodden 8 Norem 10 Royce 10 Castilla 12 Prickett 14این شکل خروجی شاید اولش عجیب باشد،ولی برای پردازش ماشین‌محور عالی است و سریع.کار روی بازه‌ها (اینجا قدرت ZSET معلوم می‌شود)فرض کن فقط راننده‌هایی را می‌خواهیم که ۱۰ امتیاز یا کمتر گرفته‌اند.ZRANGEBYSCORE racer_scores -inf 10خروجی:Ford Sam-Bodden Norem Royceاینجا داریم به Redis می‌گوییم:از منفی بی‌نهایتتا ۱۰هر چی توی این بازه است را بدهاین یعنی فیلتر + مرتب‌سازی با هم، آن هم با پیچیدگی مناسب.حذف داده‌ها (تکی و گروهی)حذف یک راننده‌ی خاص خیلی ساده است:ZREM racer_scores "Castilla"اما قدرت واقعی اینجاست که بتوانی یک بازه را پاک کنی.مثلاً:همه‌ی کسانی که امتیازشان کمتر از ۱۰ است را حذف کنZREMRANGEBYSCORE racer_scores -inf 9Redis تعداد آیتم‌های حذف‌شده را برمی‌گرداند،که برای مانیتورینگ خیلی مهم است.بعد از حذف، اگر دوباره لیست را ببینیم:ZRANGE racer_scores 0 -1خروجی:Norem Royce Prickettگرفتن رتبه‌ی یک عضویکی از مهم‌ترین قابلیت‌های Sorted Set این است که بپرسی:«این شخص چندمه؟»ZRANK racer_scores "Norem"خروجی:0یعنی از پایین، اولین نفر.اگر رتبه از بالا را بخواهی (حالت لیدربورد واقعی):ZREVRANK racer_scores "Norem"خروجی:2یعنی نفر سوم از بالا.این دستور برای نمایش رتبه‌ی کاربر بدون گرفتن کل لیدربورد حیاتی است.مرتب‌سازی لغوی (Lexicographical) — وقتی همه امتیاز برابرنداز Redis 2.8 به بعد، اگر همه‌ی اعضا score یکسان داشته باشند،می‌توانی از Sorted Set به‌عنوان ایندکس لغوی استفاده کنی.بیایم همه راننده‌ها را با score صفر اضافه کنیم:ZADD racer_scores 0 "Norem" 0 "Sam-Bodden" 0 "Royce" 0 "Castilla" 0 "Prickett" 0 "Ford"حالا اگر لیست را بگیریم:ZRANGE racer_scores 0 -1خروجی:Castilla Ford Norem Prickett Royce Sam-Boddenکاملاً لغوی مرتب شده‌اند.گرفتن بازه‌ی لغویمثلاً همه‌ی اسم‌هایی که بین A و L هستند:ZRANGEBYLEX racer_scores [A [Lخروجی:Castilla Ford براکت [ یعنی شامل (inclusive)و می‌توانی بازه‌های باز یا بی‌نهایت هم تعریف کنی.چرا این قابلیت خیلی مهم است؟چون Sorted Set فقط برای لیدربورد نیست.با این تکنیک می‌توانی:ایندکس بسازیروی بازه‌های عددی بزرگ (مثلاً 128 بیت) جستجو کنیبدون دیتابیس سنگین، range query واقعی داشته باشیRedis این کار را با یک ساختار دوگانه انجام می‌دهد:Skip List برای مرتب‌سازیHash Table برای دسترسی سریعبه همین دلیل:اضافه‌کردن عضو: O(log N)خواندن داده‌ی مرتب: تقریباً بدون هزینهآپدیت امتیازها: چرا Sorted Set برای لیدربورد ایده‌آل است؟قبل از رفتن به مبحث بعدی، یک نکته‌ی بسیار مهم درباره‌ی Sorted Set وجود دارد که اگر درک نشود، کل ارزش آن از دست می‌رود:امتیاز (score) اعضای Sorted Set هر لحظه قابل تغییر است.و مهم‌تر از آن:این تغییر با پیچیدگی O(log N) انجام می‌شود.یعنی حتی اگر میلیون‌ها عضو داشته باشی،آپدیت امتیاز هنوز هم قابل‌اعتماد و سریع است.به همین دلیل است که Sorted Set انتخاب پیش‌فرض برای leaderboard محسوب می‌شود.لیدربورد در دنیای واقعی یعنی چه؟تصور کن یک بازی آنلاین داری (مثلاً بازی‌های اجتماعی شبیه بازی‌های فیسبوکی):می‌خواهی همیشه بتوانی Top-N را نشان بدهیمی‌خواهی به هر کاربر بگویی:«رتبه‌ی تو الان 4932 است»امتیازها مدام تغییر می‌کنندتعداد آپدیت‌ها خیلی زیاد استاگر این را با دیتابیس رابطه‌ای یا سورت در کد انجام بدهی،سیستم خیلی زود تحت فشار قرار میگیره.Sorted Set دقیقاً برای همین سناریو طراحی شده.دو مدل آپدیت امتیاز در لیدربورددر عمل، دو حالت داریم:حالت اول: امتیاز جدید را دقیق می‌دانیممثلاً بازی تمام شده و امتیاز نهایی مشخص است.در این حالت، ZADD کافی است.ZADD racer_scores 100 "Wood" ZADD racer_scores 100 "Henshaw"اگر همان عضو دوباره اضافه شود:ZADD racer_scores 150 "Henshaw"اینجا Redis:عضو جدید اضافه نمی‌کندفقط امتیاز را جایگزین می‌کندو جایگاه عضو در لیدربورد را به‌روزرسانی می‌کندنکته‌ی ظریف:مقدار برگشتی 0 استیعنی عضو از قبل وجود داشتهحالت دوم: می‌خواهیم امتیاز را افزایش بدهیمدر خیلی از بازی‌ها، امتیاز تجمعی است:هر برد → +50هر مأموریت → +20اینجا استفاده از ZINCRBY منطقی‌تر است.ZINCRBY racer_scores 50 "Wood"خروجی:"150"Redis امتیاز جدید را برمی‌گرداند.حالا اگر همین کار را برای Henshaw انجام بدهیم:ZINCRBY racer_scores 50 "Henshaw"خروجی:"200"اینجا اتفاقات مهمی افتاده:امتیاز قبلی مهم نیستRedis خودش جمع می‌زندرتبه بلافاصله اصلاح می‌شودبدون race condition، بدون lock، بدون دردسر.تفاوت رفتاری ZADD و ZINCRBY (خیلی مهم)ZADDامتیاز را جایگزین می‌کندوقتی امتیاز نهایی را می‌دانیZINCRBYامتیاز را افزایش یا کاهش می‌دهدوقتی امتیاز مرحله‌ای یا تجمعی استاگر این دو را اشتباه استفاده کنی،لیدربوردت به‌مرور غلط و غیرقابل اعتماد می‌شود.دستورات پایه‌ای که لیدربورد روی آن‌ها می‌چرخدبدون وارد شدن به لیست بلندبالا، لیدربورد واقعی معمولاً فقط به این‌ها نیاز دارد:ZADDاضافه‌کردن یا آپدیت امتیازZRANGEگرفتن لیست مرتب‌شده (از پایین به بالا)ZRANKگرفتن رتبه‌ی کاربر از پایینZREVRANKگرفتن رتبه‌ی کاربر از بالا (حالت لیدربورد)با همین چهار دستور می‌توان یک لیدربورد کامل ساخت.نکته‌ی عملکردی که نباید نادیده بگیریبیشتر عملیات‌های Sorted Set:O(log N) هستندو برای آپدیت‌های پرتعداد عالی‌انداما یک هشدار جدی وجود دارد:اگر ZRANGE را با خروجی خیلی بزرگ صدا بزنی(مثلاً ده‌ها هزار یا صدها هزار عضو)،هزینه‌اش دیگر فقط لگاریتمی نیست.در این حالت:هزینه می‌شود O(log N + M)که M تعداد آیتم‌های برگشتی استنتیجه‌ی عملی:لیدربورد را صفحه‌بندی‌شده بگیر، نه یک‌جا.اگر Sorted Set تنها کافی نبود چه؟گاهی Sorted Set فقط نقش ایندکس را دارد،و داده‌ی اصلی جای دیگری است.در این سناریوها:می‌توانی ZSET را برای رتبه‌بندی نگه داریو دیتای واقعی را در ساختارهای دیگر ذخیره کنییا سراغ امکانات Query و JSON در Redis برویاما این تصمیم، بعد از درک درست Sorted Set گرفته می‌شود، نه قبلش.سخن پایانیبا رشد سیستم‌های بلادرنگ، حجم بالای داده و نیاز به پاسخ‌دهی سریع در محصولات دیجیتال، انتخاب درست ساختار داده و الگوی معماری نقش مستقیمی در مقیاس‌پذیری و پایداری سامانه‌ها دارد. Redis و به‌ویژه Sorted Set نمونه‌ای از ابزارهایی هستند که اگر درست درک و استفاده شوند، می‌توانند بخش مهمی از پیچیدگی سیستم‌هایی مثل لیدربورد، رتبه‌بندی و محدودسازی درخواست‌ها را به‌صورت ذاتی حل کنند.اگر در حال طراحی یا بازطراحی سامانه‌هایی با بار بالا، نیاز به رتبه‌بندی، یا منطق‌های real-time هستید، تیم معماری و توسعهٔ نرم‌افزار شرکت راهکار نگار هوشمند (آرکان) می‌تواند از تحلیل مسئله تا طراحی معماری و پیاده‌سازی عملیاتی، همراه شما باشد.این مقاله با هدف انتقال تجربه و آگاهی‌بخشی فنی، توسط تیم توسعهٔ نرم‌افزار شرکت راهکار نگار هوشمند (آرکان) تهیه شده است.#Redis#SortedSet#Leaderboard#Scalable_Systems#Backend_Architecture#System_Design#High_Performance#RealTime_Systems#Data_Structures#Software_Engineering#DevTools#شرکت_راهکار_نگار_هوشمند#arcanco

معماری MaMa-CRM در قالب arc42

محمد حسین جلیلی — Sun, 14 Dec 2025 14:36:18 +0330

در ادامهٔ مجموعه مقالات ما دربارهٔ مستندسازی معماری با الگوی arc42، اینبار به سراغ یکی از مهمترین و پیچیدهترین مثالها میرویم: سیستم MaMa-CRM؛ سامانهای واقعی، عملیاتی و بزرگ که در دنیای کسبوکارهای انبوه (Mass Market) بهکار گرفته میشود.MaMa-CRM برای سازمانهایی طراحی شده که روزانه با میلیونها مشتری سر و کار دارند؛سازمانهایی مثل:شرکتهای بیمهاپراتورهای تلفن همراهارائهدهندگان خدمات انرژی و آببانکها و شرکتهای کارت اعتباریشرکتهای بزرگ مدیریت املاکدر چنین بازارهایی، ارتباط با مشتری معمولاً گسترده، تکرارشونده و در مقیاس بسیار بزرگ است. در بسیاری از این صنایع، این ارتباطها سالها روی کاغذ مدیریت میشد. وظیفهٔ MaMa-CRM این بود که این بار سنگین را از دوش سازمانها بردارد و بهصورت دیجیتال و خودکار مدیریت کند.جالبتر اینکه MaMa-CRM ابتدا برای یک پروژهٔ بسیار مهم و حساس ساخته شد:پشتیبانی از راهاندازی “کارت سلامت الکترونیک آلمان”.بعدها همین پلتفرم در کمپینهایی مثل صدور قبوض تلفن، قرائت کنتور برق، مدیریت اطلاعات مشترکین و موارد مشابه نیز استفاده شد.یکی از ویژگیهای منحصربهفرد این سیستم این است که:برای هر مشتری سازمانی (Mandator)، یک نسخه کاملاً مستقل و جداگانه از MaMa-CRM اجرا میشود.این استقلال باعث میشود هر سازمان بتواند بهصورت اختصاصی، با پیکربندی مخصوص خود و برای کمپینهای خاص خود از سیستم استفاده کند. همین نیاز به انعطافپذیری عمیق موجب شد تصمیمات معماری مهمی در طراحی MaMa-CRM گرفته شود—و این مثال را به یک نمونه ایدهآل برای آموزش arc42 تبدیل میکند.تیم توسعهٔ MaMa-CRM شامل ۷ تا ۱۰ نفر بود که طی ۱۵ ماه، در اسپرینتهای ۲ تا ۴ هفتهای روی این پروژه کار کردند.خود گرنوت استارکه (نویسندهٔ arc42) یکی از اعضای اصلی این تیم بوده و اجازه یافته دربارهٔ این سیستم صحبت کند—البته بدون افشای نام شرکت.در این مقاله، ما قصد داریم:معماری سیستم MaMa-CRM را از زاویهٔ الگوی arc42 بررسی کنیمنیازمندیهای کلیدی و چالشهای طراحی را تحلیل کنیمو ببینیم چگونه یک سیستم واقعی در دنیای کسبوکارهای انبوه میتواند از مستندسازی معماری بهره ببرداین مثال، برخلاف HSC، کاملاً صنعتی، بزرگ و چندلایه است؛به همین دلیل، بهترین نمونه برای یادگیری معماری سیستمهای واقعی محسوب میشود.III.1 مقدمه و اهداف سیستم MaMa-CRMسیستم MaMa-CRM یک پلتفرم نرمافزاری گسترده و انعطافپذیر است که برای مدیریت و هماهنگی فرآیندهای ارتباط با مشتری در کسبوکارهای انبوه طراحی شده است؛ کسبوکارهایی که میلیونها مشتری دارند و تعاملات روزانهشان آنقدر زیاد است که مدیریت آنها بهصورت دستی یا کاغذی کاملاً غیرواقعی و پرخطا میشود.این پلتفرم بهگونهای ساخته شده که بتواند برای صنایع مختلف، با نیازهای کاملاً متفاوت، پیکربندی شود—بدون آنکه نیاز به تغییر کد داشته باشد. همین موضوع، MaMa-CRM را از یک «سامانهٔ ساده» به یک خانوادهٔ محصول (Product Family) تبدیل میکند؛ سیستمی که هستهٔ مشترک دارد، اما هر مشتری سازمانی میتواند نسخهٔ اختصاصی خود را دریافت کند.MaMa-CRM توسط چه سازمانی توسعه و راهبری میشود؟این سیستم توسط یک دیتاسنتر نوآور (که در این متن “InDAC” نامگذاری شده) ساخته و پشتیبانی شده است—شرکتی که خدمات نرمافزاری مدیریتشده (Hosted Services) برای سازمانهای بزرگ ارائه میدهد.InDAC بهعنوان پیمانکار، برای هر یک از mandatorها (سازمان مشتری) یک نسخهٔ مستقل از MaMa-CRM را اجرا و عملیاتی میکند.مسئلهای که MaMa-CRM حل میکند چیست؟کسبوکارهای انبوه—مانند بیمه، مخابرات، بانکداری و مدیریت انرژی—نمیتوانند ارتباطات مشتری را بهصورت دستی مدیریت کنند.این ارتباطات شامل:ارسال پیشنهادهای جدیداطلاعرسانی تغییرات قرارداددریافت بازخورد مشتریجمعآوری اسناد یا تأییدیههاپیگیری وضعیت ارتباطاتاست و معمولاً از چندین کانال مختلف انجام میشود:ایمیل، پیامک، تماس تلفنی، فکس، نامه، یا حتی مراجعه حضوری.بدون یک سیستم متمرکز، این ارتباطات:گم میشوندخطا دارندقابل نظارت نیستندو کیفیت خدمات بهشدت افت میکندMaMa-CRM برای حل همین مشکل طراحی شده است.چند مثال واقعی از استفادهٔ MaMa-CRMبرای درک بهتر دامنهٔ سیستم، چند نمونه از کمپینهای رایج که MaMa-CRM پشتیبانی میکند را مرور میکنیم:۱) مدیریت تغییرات قرارداد و تعرفههای جدید (Telecom، Insurance، ISP)مثلاً:اپراتور تلفن همراه یک طرح جدید ارائه میدهد و مشتریان باید تأیید کنند، سؤال بپرسند یا نظرشان را اعلام کنند.MaMa-CRM تمام این تعاملات را ساماندهی میکند.۲) ارسال صورتحساب و رسیدگی به پشتیبانی (Call-by-call Providers)Mandator دادههای صورتحساب را به MaMa ارسال میکند و سیستم:چاپ قبضهاارسال آنهاو مدیریت درخواستهای پشتیبانیرا هماهنگ میکند.(تسویه حساب مالی خارج از محدودهٔ سیستم است.)۳) مدیریت عکسهای کارتها (Credit Cards، Insurance، e-Health Card)در برخی سیستمها، عکس مشتری باید روی کارت چاپ شود.MaMa-CRM مدیریت ذخیره، پردازش و تخصیص این تصاویر را انجام میدهد.۴) قرائت کنتور برق، آب یا گازشرکتهای انرژی یا املاک از MaMa-CRM برای:جمعآوری دادهپیگیری وضعیتو مدیریت چرخهٔ ارتباط با مشتریاناستفاده میکنند.تمرکز اصلی معماری MaMa-CRM: انعطافپذیری شدیداز آنجا که MaMa-CRM قرار است برای صنایع مختلف، با ورودیها، خروجیها، کانالها و فرآیندهای کاملاً متفاوت استفاده شود، یک الزام کلیدی وجود دارد:سیستم باید بدون تغییر کد، برای هر mandator و هر کمپین قابل پیکربندی باشد.این نیاز معماری را بهشدت تحت تأثیر قرار داده و باعث شده طراحی سیستم بر پایهٔ موارد زیر انجام شود:جداسازی کامل هستهٔ سیستم از اجزای پیکربندیشوندهپشتیبانی از کانالهای مختلف ارتباطیپشتیبانی از مدلهای مختلف دادهپشتیبانی از انواع متفاوت فرآیندهای کاریاجرای نسخههای کاملاً مستقل برای هر mandatorاین نیازمندیها بسیاری از تصمیمات معماری مهم را شکل دادهاند که در بخشهای بعدی arc42 به آنها خواهیم پرداخت.III.1.1 – مرور نیازمندیها Requirements OverviewMaMa-CRM یک سیستم بسیار انعطافپذیر و چندمنظوره است که برای پشتیبانی از کمپینهای CRM در مقیاس انبوه طراحی شده.در این سیستم، سازمانهایی مانند:اپراتورهای تلفن همراهشرکتهای بیمهارائهدهندگان اینترنتشرکتهای انرژی و آبو حتی مؤسسات مدیریت املاکنقش «Mandator» یا مشتری سازمانی را دارند.این سازمانها بخشی از فرآیندهای ارتباط با مشتریشان را به شرکت InDAC واگذار میکنند، و InDAC با استفاده از MaMa-CRM آنها را بهصورت حرفهای اجرا و مدیریت میکند.به بیان سادهتر:MaMa-CRM، مغز عملیاتی کمپینهای بزرگ ارتباط با مشتری است.و باید بتواند با سازمانهایی کار کند که میلیونها مشتری دارند و تعاملاتشان از دهها مسیر مختلف وارد سیستم میشود.کمپینهایی که MaMa-CRM باید پشتیبانی کندبرای اینکه MaMa-CRM یک پلتفرم واقعی و صنعتی باشد، باید بتواند چند نوع کمپین CRM را بدون تغییر کد، تنها با پیکربندی پشتیبانی کند. برخی از مهمترین سناریوها عبارتاند از:۱) تغییر تعرفه یا بهروزرسانی قراردادهادر صنایع مانند بیمه، مخابرات، اینترنت یا انرژی، قراردادها و تعرفهها دائماً تغییر میکنند.ماجرا گاهی ساده است (بهروزرسانی قیمت)، اما اغلب پیچیدهتر:مشتری باید آگاه شودباید تصمیم بگیردپاسخ از کانالهای مختلف میرسدو درصورت پذیرش، قرارداد باید بهصورت قانونی آپدیت شودMaMa-CRM باید بتواند همهٔ این اتفاقات را هماهنگ کند.۲) پردازش اطلاعات صورتحساببرای مثال:شرکتهای «call-by-call» دادههای خام صورتحساب را به MaMa میفرستند.MaMa:دادهها را دریافت و پردازش میکندآنها را برای چاپ و ارسال آماده میکندو پشتیبانی لازم پس از ارسال را مدیریت میکندپرداخت و امور مالی خارج از محدودهٔ سیستم هستند.۳) مدیریت تصاویر کارتها (Credit Card / Insurance / e-Health Card)بسیاری از کارتها مانند کارت سلامت آلمان، تصویر دارنده را روی کارت چاپ میکنند.MaMa-CRM باید بتواند:تصاویر را ذخیره کندمدیریت چرخه پردازش را انجام دهدو نتیجه را برای چاپگر کارت آماده کند۴) مدیریت قرائت کنتور آب/برق/گازشرکتهای انرژی یا املاک، دادههای مربوط به قرائت کنتور را جمعآوری و مدیریت میکنند.MaMa-CRM باید فرآیند جمعآوری داده، هماهنگی، پاسخگویی و پردازش را مدیریت کند.نکتهٔ کلیدی معماری: انعطافپذیری مطلق در ورودی/خروجیچون MaMa-CRM نقش یک «پلتفرم CRM چندصنعتی» دارد، یک الزام بزرگ وجود دارد:MaMa-CRM باید بدون نیاز به تغییر کد، برای هر Mandator و هر کمپین قابل پیکربندی باشد.این یعنی:فرمتهای مختلف داده باید پشتیبانی شوندکانالهای ارتباطی مختلف باید قابل انتخاب باشندفرآیندها باید قابل تغییر و تنظیم باشندسیستم باید بتواند با انواع OCR، چاپگر، مرکز تماس، API و غیره صحبت کندهمین الزام پایهٔ بسیاری از تصمیمات معماری MaMa-CRM بوده است.III.1.1.1 مثال کمپین: اصلاح قرارداد مشترکین یک اپراتور موبایلبرای درک بهتر دامنه و پیچیدگی سیستم، مثال MoPho—a hypothetical mobile provider—در کتاب آورده شده است.این مثال، ترکیبی از چالشهای تجاری، حجم دیتای بالا و کار عملیاتی است.MoPho میلیونها مشترک دارد و قصد دارد تعرفههای قدیمی و غیرسودده خود را حذف کند. بنابراین:تعرفههای جدید را طراحی میکند.مشتریان واجد شرایط را انتخاب میکند (حدود ۱۰ میلیون نفر).پیشنهاد جدید را برای آنها ارسال میکند.به واکنش مشتریان از هر کانال ممکن پاسخ میدهد.و در صورت پذیرش، قرارداد جدید را ثبت میکند.MoPho خودش نمیخواهد با پیچیدگیهای عملیاتی درگیر شود:چاپ نامهمدیریت بازگشت نامههاپاسخگویی تلفنیپردازش فاکسOCR و پردازش فرمهاتشخیص خطاهای مشتریانمدیریت استثناهاو صدها حالت مختلف تعامل انسانیاینها خارج از حوزهٔ تخصص اپراتور هستند.بنابراین همهٔ این فرایندها را به MaMa-CRM میسپارد.چرخهٔ کامل این کمپین—گامبهگام۱) انتخاب و ارسال داده مشتریان به MaMaMoPho داده ۱۰ میلیون مشتری را استخراج و به MaMa ارسال میکند.MaMa آنها را وارد سیستم میکند.۲) ارسال داده لازم برای چاپ نامهMaMa اطلاعات لازم را به شرکت چاپ (Partner) میفرستد.این شرکت نامههای شخصیسازی شده را تولید و ارسال میکند.۳) آمادهسازی مرکز تماس (Partner)MaMa اطلاعات کمپین را برای Call Center ارسال میکند تا آمادهٔ پاسخگویی باشند.۴) مدیریت نامههای برگشتی یا ردشدهPostal Service موارد زیر را گزارش میدهد:آدرس اشتباهForwarding requestمشتری نامه را نپذیرفتهMaMa این موارد را تحلیل و تصمیم لازم را میگیرد.۵) مشتری تصمیم میگیردو حالتهای مختلف رخ میدهد:فرم را کامل میکند و امضا میکندفرم را پر میکند اما امضا نمیکندفرم ناقص ارسال میشودمشتری از طریق تلفن سؤال میکندمشتری بیتفاوت استیا شرایط ویژه وجود دارد: زیر سن قانونی، فوت شده، ناتوانی حقوقی و…۶) فرمها اسکن و OCR میشوندشرکت Partner فرمها را اسکن و نتیجه را برای MaMa ارسال میکند.۷) MaMa نتایج را دریافت و تحلیل میکند۸) تصمیمگیری براساس وضعیت هر مشتریMaMa باید همهٔ حالات ممکن را مدیریت کند—از کامل بودن تا ناقص بودن یا عدم ارسال.۹) بهروزرسانی اطلاعات در سیستم Mandatorدر نهایت، قراردادهای جدید برای مشتریانی که پذیرش کردهاند ثبت میشود.مزیت اصلی برای اپراتور چیست؟MoPho یک چیز بهدست میآورد:یک نقطهٔ مرکزی برای مدیریت کل کمپین—بدون نیاز به دخالت مستقیم.و این یعنی:هزینه کمترسرعت بالاترکیفیت پاسخگویی بهترکاهش خطاامکان مدیریت میلیونها مشتریو مخصوصاً:انعطافپذیری بینهایت در هماهنگسازی با انواع سیستمها و شرکای بیرونی.1.1.2 Campaign Configuration – پیکربندی کمپینها در MaMa-CRMMaMa-CRM یک پلتفرم عمومی نیست که بتوان آن را «نصب و اجرا» کرد.این سیستم یک زیرساخت CRM چندمنظوره است که برای هر Mandator (سازمان مشتری) باید:پیکربندی شودشخصیسازی شودبه چندین شریک (Partner) متصل شودو همهٔ این موارد بدون تغییر کد انجام شوندبهعبارت دیگر:هر کمپین در MaMa مانند یک سیستم مستقل است که کاملاً با تنظیمات ساخته میشود.در ادامه، مراحل اصلی پیکربندی یک کمپین—با مثال MoPho—را مرور میکنیم.۱) پیکربندی دادههای اصلی مشتری (Client Master Data)این مرحله معمولاً توسط خود Mandator تأمین میشود و شامل تعریف تمام اطلاعات لازم دربارهٔ:قرارداد مشتریتعرفه فعلیتعرفههای پیشنهادی جدیدتاریخ اعتبار قرارداد فعلیتاریخ شروع تعرفهٔ جدیداین دادهها در قالب مدلهای UML بهعنوان Extension روی مدل پایهٔ MaMa اعمال میشوند.به این ترتیب:مدل پایه ثابت میمانداما برای هر صنعت (Telecom، Insurance، Banking…) دادههای اختصاصی تعریف میشوداین بخش یکی از مهمترین پایههای انعطافپذیری معماری است.۲) پیکربندی کانالهای ارتباطیMaMa-CRM باید با چندین Partner و Mandator ارتباط داشته باشد، بنابراین نیاز است:تبادل اطلاعات امنیتی مانند رمز عبور، Certificate و User IDتعریف کانالهای تبادل دادهمشخص کردن نقطه تماس فنی در هر سازماناین کانالها میتوانند شامل:اتصال به Print Service Providerاتصال به Call Centerاتصال به Scan Service Providerارتباط با سیستمهای IT خود Mandatorباشند.۳) تعریف فراداده کمپین (Campaign Meta Data)برای اینکه یک کمپین CRM بتواند اجرا شود، باید ابتدا:تاریخ شروع و پایان کمپینتاریخهای مهم برای فعالیتهاآدرسهای پاسخ (Reply Address)ایمیل و شمارهٔ اختصاصی Call Centerتعریف شوند.این اطلاعات برای هماهنگی هزاران یا میلیونها تعامل انسانی ضروری است.۴) تعریف فعالیتهای کمپین (Campaign Activities)در MaMa هر کمپین از چندین فعالیت تشکیل شده است که در سه گروه اصلی قرار میگیرند:الف) فعالیتهای خروجی (Output Activities)کارهایی که MaMa باید برای ارسال داده انجام دهد، مثلاً:ارسال داده به شرکت چاپ: PrintLetterارسال داده به Call Centerارسال داده به Scan Service Providerارسال نتایج نهایی به Mandatorارسال سفارش تولید کارت (Card Production Order)ب) فعالیتهای ورودی (Input Activities)دادههایی که MaMa باید از Mandator یا Partners دریافت کند:دادههای اولیه مشتریان (Master Data Import)دادههای OCR پس از اسکن فرمهادادههای Call Centerخروجی فروشگاههای حضوری (Sales Outlet Import)ج) فعالیتهای داخلی (Internal Activities)کارهای نگهداری و پاکسازی دیتای حساس، مانند:حذف دادهٔ مشتری ۶۰ روز پس از پایان پردازشحذف کل دادههای کمپین ۱۲۰ روز پس از پایان رسمی کمپین(این موارد برای رعایت قوانین امنیت و حریم خصوصی ضروریاند.)۵) مدلسازی جریان کمپین (Campaign Flow Modeling)پس از تعریف فعالیتها، باید مشخص شود:چه فعالیتی در چه شرایطی اجرا میشود؟مسیرهای خوشرفتار (Happy Path) و مسیرهای خطا چیست؟اگر داده ناقص باشد چه باید کرد؟اگر مشتری پاسخ ندهد چه اتفاقی میافتد؟چگونه plausibility validation انجام میشود؟این مدل کسبوکار پیچیده، یکی از تفاوتهای اساسی MaMa-CRM با یک CRM معمولی است.1.1.3 فعالیتهایی که هزینه ایجاد میکنند (Activities Subject to Charge)در بسیاری از کمپینها، بعضی فعالیتها هزینهٔ مستقیم مالی دارند، مانند:چاپ و ارسال نامه برای مشتریتولید کارت برای بیمه یا کارت بانکی (Card Production Charges)از آنجا که ممکن است میلیونها فعالیت در یک کمپین انجام شود، هزینهها بسیار قابلتوجه هستند.نکتهٔ مهم:MaMa-CRM مسئول مدیریت مالی یا تسویه حساب نیست.صورتحساب و پرداختها توسط واحد مالی InDAC یا خود Mandator مدیریت میشود.MaMa فقط باید:تعداد فعالیتهاوضعیت پیگیریو گزارش دقیق برای حسابداریرا ارائه دهد.1.1.4 نیازمندیهای تکمیلیدر این بخش چند الزام مهم و غیرقابلچشمپوشی مطرح میشود:۱) گزارشدهی وضعیت و گزارشهای مالیMaMa باید گزارشهای جامع ارائه دهد، شامل:تعداد نامههای ارسالشدهتعداد تماسهای Call Centerتعداد فرمهای بازگشتیتعداد مشتریانی که تغییر تعرفه را پذیرفتهاندو بهویژه:گزارش دقیق فعالیتهای دارای هزینه.این گزارشها پایهٔ محاسبهٔ هزینهها در InDAC است.۲) مالکیت داده و الزامات امنیتییک اصل بنیادین در MaMa-CRM:دادهٔ مشتری همیشه متعلق به Mandator است، نه InDAC.این یعنی:داده باید محرمانه نگه داشته شودفقط برای همان کمپین استفاده میشودپس از پایان رسمی کمپین،تمام دادهها—شامل Backup، پیکربندی، Metadata—باید حذف شونداین الزام معماری را بهشدت تحت تأثیر قرار میدهد، مخصوصاً در بخشهای دیتابیس، ذخیرهسازی و جریان داده.1.2 اهداف کیفی MaMa-CRM – چرا «انعطافپذیری» مهمترین اصل معماری است؟اگر بخواهیم فقط یک واژه برای توصیف هویت معماری MaMa-CRM انتخاب کنیم، آن واژه Flexibility یا «انعطافپذیری» است.MaMa-CRM در اصل یک Data Hub بسیار تطبیقپذیر است؛ سیستمی که باید بتواند:از دهها نوع منبع داده ورودی دریافت کندقوانین تجاری کاملاً متفاوت را اجرا کندداده را به انواع شرکای تجاری صادر کندو این کار را بدون تغییر کد و تنها با «پیکربندی» انجام دهداین نیازها باعث شده معماری MaMa-CRM حول محور چهار نوع انعطافپذیری طراحی شود:Aspect 1 — انعطافپذیری در ساختار و فرمت دادهMaMa در تمام کمپینها با دادهٔ مشتری سر و کار دارد؛ اما مشکل اینجاست که:هر Mandator (بیمه، بانک، تلفن همراه، انرژی…)هر Partner (چاپ، مرکز تماس، OCR، فروشگاهها)همه فرمت دادهٔ مخصوص خودشان را دارند.MaMa باید همهٔ این فرمتها را پشتیبانی کند، از جمله:فرمتهای متداولCSV با جداکنندههای مختلف (, ، ; ، | و…)رشتههایی با کوتیشنهای مختلف (" , ' , « »)فایلهایی با طول ثابت (Fixed-Length Records)مجموعهای از XMLهای متفاوت با Schema یا DTDهای سفارشیاما مهمتر اینکه:MaMa باید بتواند بدون تغییر کد، فرمت هر Mandator را فقط با پیکربندی قبول کند.بنابراین سیستم باید:ترتیب ستونهاانواع دادههاقواعد اعتبارسنجی (Validation & Plausibility Checks)را برای هر کمپین بهطور سفارشی پیکربندی کند.Aspect 2 — انعطافپذیری در روشها و پروتکلهای انتقال دادهMaMa فقط با فرمتها سروکار ندارد—بلکه باید داده را از طریق چندین کانال مختلف دریافت و ارسال کند.MaMa باید بتواند کار کند با:ftp و sftphttp و https(هم به عنوان Client و هم Server)و همچنین باید بتواند:دادهٔ فشردهشده را بپذیرد (Compression الگوریتممحور و قابل پیکربندی)دادهٔ رمزگذاریشده را مدیریت کند (PGP یا مشابه آن)چکسام تولید کند (MD5، SHA-1 یا شمارندههای مخصوص)Credentials اختصاصی هر Mandator را مدیریت کندبه زبان ساده:هر کمپین باید بتواند کانال ارتباطی مخصوص خودش را داشته باشد.این سطح از انعطافپذیری الزامات امنیتی، کارایی و سازگاری را مستقیماً تحت تأثیر قرار میدهد.Aspect 3 — انعطافپذیری در قوانین تجاری و قوانین کمپیناینجا جایی است که MaMa-CRM از یک سیستم ساده به یک «پلتفرم فرآیندی» تبدیل میشود.برای هر کمپین باید بتوان پیکربندی کرد:قوانین اساسی کمپین:کدام فعالیتها باید انجام شوند؟ترتیب اجرای فعالیتها چیست؟چه رویدادهایی از طرف Partner باید باعث اجرای کدام فعالیت شوند؟قوانین تعامل با مشتری:چند بار باید نامهٔ یادآوری ارسال شود؟چه زمانی باید مشتری را تلفنی پیگیری کرد؟کدام اطلاعات از مشتری الزامی است؟چه زمانی باید دادهها حذف یا آرشیوشده شوند؟قوانین واکنشی:اگر مشتری پاسخ نداد چه کنیم؟اگر فرم ناقص بود چه کنیم؟اگر امضا نداشت، چطور پیگیری کنیم؟اینها قوانین ثابتی نیستند؛هر Mandator قوانین مخصوص خودش را دارد، و MaMa باید همهٔ آنها را بدون تغییر کد پشتیبانی کند.Aspect 4 — انعطافپذیری در خروجی دادهپس از پردازش دادههای مشتری، MaMa باید نتیجه را به چند Partner مختلف ارسال کند.هر Partner الزامات خاص خود را دارد:شرکت چاپ → فرمت Fixed-Lengthمرکز تماس → CSVسیستم کارت سلامت → XMLMandator → فرمت سفارشیبه همین دلیل، معماری MaMa-CRM باید بتواند:از یک ورودی مشترک، چندین خروجی متفاوت بسازد—کاملاً با نیاز هر Partner.یک سناریوی واقعی:داده از Mandator به صورت CSV وارد MaMa میشودMaMa آن را پردازش میکندبخشی از داده باید به Partner A به صورت XML صادر شودبخش دیگر باید به Partner B در قالب Fixed-Length فرستاده شوداین نیاز، طراحی لایههای Import / Processing / Export را عمیقاً تحت تأثیر قرار میدهد.1.2.2 Quality Goals (Scenarios) — کیفیتهای سطح ۱کیفیت شماره یک MaMa-CRM، Flexibility است؛ اما باید بهصورت سناریوی عملی تعریف شود تا معماری سیستم بتواند حول آن طراحی شود.Prio = 1 (بالاترین اولویت)سناریوهای کیفیتی شامل این موارد هستند:۱) MaMa میتواند فرمتهای مختلف داده را Import / Export کند:CSV قابل پیکربندیFixed-LengthXML۲) MaMa میتواند از چندین پروتکل ارتباطی استفاده کند:ftp، sftp، http، httpsهمزمان Client و Server۳) دادهٔ فشرده و رمزگذاریشده را مدیریت میکندالگوریتم فشردهسازی قابل تنظیمPGP یا ابزارهای مشابه برای رمزگذاریتبادل امن Certificateها پیش از شروع کمپین۴) مدیریت Metadata مربوط به انتقالمثلاً:هش فایلشمارندهٔ انتقالثبت آخرین انتقال موفق۵) تمام این موارد باید طی یک روز قابل پیکربندی باشنداین نیاز باعث شده بخش "Campaign Configuration" پایهٔ اصلی معماری شود.1.2.2 اهداف کیفی سطح دوم و سوماولویت ۲: امنیت (Security)در MaMa-CRM، امنیت فقط یک ویژگی فنی نیست؛ هستهٔ وجودی سیستم است.این پلتفرم حجم عظیمی از دادههای حساس مشتریان را میان Mandatorها، شرکای تجاری، و زیرساخت InDAC جابهجا میکند—و کوچکترین نشت داده میتواند یک بحران حقوقی، مالی و اعتباری ایجاد کند.بنابراین:هیچ طرف بیرونی کمپین نباید به دادهها یا فرادادهها دسترسی داشته باشد.تمام دادهها—اعم از ورودی، خروجی، ذخیرهشده و موقت—باید در کنترل کامل InDAC باقی بماند.ادمینهای InDAC، قبل از دسترسی به دادهٔ هر کمپین، باید قرارداد عدم افشای اطلاعات امضا کنند (این بخش سازمانی است و جزئیات آن خارج از محدوده سیستم قرار میگیرد).نتیجهٔ معماری:معماری MaMa باید امنیت را در تمام لایهها در نظر بگیرد: زیرساخت، الگوهای ارتباطی، رمزگذاری، دسترسیها، تفکیک محیطها، و جداسازی دادههای Mandatorهای مختلف.اولویت ۳: کارایی اجرایی (Runtime Performance)MaMa-CRM در برخی کمپینها باید دادههایی در مقیاس کشور پردازش کند. برای مثال:سیستم باید بتواند ۲۵۰٬۰۰۰ نامه اسکنشده را در کمتر از ۲۴ ساعت پردازش کند.این الزام باعث میشود:پردازش داده باید کاملاً بهینه و موازیپذیر باشدورودی و خروجی کمپینها باید مقیاسپذیر طراحی شوندصفها، پردازشهای دستهای و مکانیزمهای Retry بخش جداییناپذیر معماری باشنداین سناریو کیفیت «Performance» را به یک الزام معماری جدی تبدیل میکند.1.2.3 موارد خارج از محدوده (Non-Goals)برای جلوگیری از انحراف معماری، MaMa-CRM بهصورت شفاف مشخص کرده چه چیزهایی در حوزهٔ وظایفش نیست:۱) MaMa یک محصول تجاری عمومی نیستMaMa قرار نیست تبدیل به نرمافزاری مشابه Salesforce، Siebel یا محصولات CRM بازار شود.این سیستم صرفاً برای استفادهٔ داخلی InDAC طراحی شده و مستقیماً برای فروش عرضه نخواهد شد.۲) MaMa جایگزین CRM سازمانی نیستMandatorها همچنان CRM اصلی خودشان را دارند؛MaMa صرفاً یک سیستم عملیات کمپین (Operational Campaign Engine) است—not یک CRM کامل.۳) MaMa فرایندهای مالی و پرداخت را مدیریت نمیکندهرچند کمپینها هزینه ایجاد میکنند (مثل چاپ نامه، کارت، تماس تلفنی و…)،پردازش مالی و پرداختها خارج از محدوده MaMa بوده و توسط بخش مالی InDAC یا خود Mandator انجام میشود.این تفکیک باعث میشود معماری MaMa سبکتر و متمرکزتر باقی بماند.1.3 ذینفعان (Stakeholders) — چه کسانی به MaMa شکل میدهند؟MaMa-CRM یک سیستم چندذینفعی است و معماری آن باید نیازهای گروههای مختلفی را برآورده کند. در ادامه، هر ذینفع را با زبان بلاگی توضیح دادهام.Mandator — سازمانهایی که کمپینها را سفارش میدهنداینها شرکتهایی هستند که InDAC را برای اجرای کمپینهای بزرگ انتخاب میکنند: بیمهها، اپراتورها، بانکها، شرکتهای انرژی و…برای Mandator مهمترین خواستهها عبارتاند از:وارد کردن دادهٔ اولیه با کمترین تلاشدریافت خروجیها در قالبهای موردنیاز خودپیکربندی سریع قوانین کمپینشفافیت کامل در گزارشدهی فعالیتهاMandatorها معمولاً دغدغهٔ اجرایی ندارند؛ آنها فقط داده میدهند، نتیجه میخواهند.مدیریت InDAC — مالک سیستم و مسئول گسترش آندر سمت InDAC، مدیریت نیاز دارد:یک پلتفرم انعطافپذیر که بتواند سالها با Mandatorهای جدید سازگار شودعملکرد بالا و قابلاتکا برای پردازش داده در مقیاس بزرگامکانی برای توسعهٔ تدریجی سیستم بر اساس نیازهای جدیدآنها در چرخهای مستمر با تیم معماری و توسعه همکاری میکنند تا نیازهای جدید تعریف شود و سیستم در طول زمان ارتقا پیدا کند.توسعهدهندگان MaMa-CRM — معماران و سازندگان سیستمتیم توسعه وظایف زیر را بر عهده دارد:طراحی ساختار داخلی MaMaپیادهسازی مؤلفهها و ماژولهامشارکت فعال در تصمیمات معماریتضمین پایداری، امنیت و مقیاسپذیریبرای آنها، MaMa یک پلتفرم در حال رشد است، نه یک محصول تمامشده.شرکای تجاری (Partners) — ارائهدهندگان خدمات جانبیاین گروه شامل:شرکتهای چاپمراکز تماسسرویسهای اسکن و OCRارائهدهندگان کارت هوشمندشرکتهای پستی و لجستیکنیاز اصلی آنها:دریافت داده از MaMa در قالبی دقیق و سازگارارسال دادهٔ پردازششده به MaMa با فرمت توافقشدهداشتن رابطهای ارتباطی پایدار و امنتعامل مؤثر MaMa با این شرکا، موفقیت کمپین را تضمین میکند.نهادهای دولتی و قانونگذاردر بسیاری از کشورها کمپینهایی مثل تغییر قرارداد بیمه یا کارت سلامت تحت مقررات سختگیرانه هستند.نهادهای دولتی وظیفه دارند اطمینان حاصل کنند:دادهٔ مشتریان بهدرستی محافظت میشودفرآیندها با قوانین IT-security و حفاظت داده سازگار هستندمحرمانگی و نگهداری داده با استانداردهای قانونی همخوان استاین نقش مستقیماً روی سیاستهای امنیتی MaMa تأثیر میگذارد.جامعه Eclipse RCP (پلتفرم UI)MaMa برای UI خود از Eclipse RCP استفاده میکند.چالش اصلی اینجاست که Eclipse API را مرتب تغییر میدهد و این موضوع روی توسعهٔ رابط کاربری MaMa اثرگذار است.بنابراین تیم MaMa باید دائماً تغییرات پلتفرم را رصد و با نسخههای جدید هماهنگ شود.۱.۳.۱ مورد ویژه: پروژهٔ کارت سلامت الکترونیک آلمان (German e-Health Card)یکی از پیچیدهترین کمپینهایی که InDAC با استفاده از MaMa-CRM میزبانی کرد، پروژهٔ آزمایشی کارت سلامت الکترونیک آلمان بود.این پروژه تحت نظارت یک نهاد دولتی تازهتأسیس انجام میشد؛ نهادی که مسئول تعریف استانداردهای فنی و امنیتی کارت سلامت بود.نکتهٔ چالشبرانگیز برای تیم MaMa-CRM:در آغاز توسعه، استانداردهای رسمی هنوز وجود نداشتند.یعنی تیم باید سیستمی طراحی میکرد که:با استانداردهایی غیرقطعی و در حال تدوین سازگار شودسطح امنیت بسیار بالا داشته باشدبتواند در آینده با الزامات رسمی منطبق گرددو هنوز انعطافپذیری گسترده MaMa را حفظ کنداین سناریو یکی از نقاطی بود که «اهمیت انعطافپذیری» در معماری MaMa را بهشدت برجسته کرد.۱.۳.۲ نقش Mandator و Partner در تعیین جزییات ارتباطیMaMa-CRM مجموعهای از اسناد استاندارد مشخصات اتصال ارائه میدهد؛ اسنادی که باید توسط شرکای کمپین (مثل چاپ، اسکن، مرکز تماس، شرکت پستی و…) برای اتصال به MaMa استفاده شوند.اما در عمل همیشه اینگونه پیش نمیرود.به دلیل انعطاف زیاد MaMa، معمولاً اتفاق برعکس میافتد:Mandatorها و Partnerها فرمت داده و قرارداد ارتباطی خودشان را ارائه میکنند،و MaMa فقط آنها را پیکربندی میکند—بدون تغییر کد.این ویژگی برای InDAC یک مزیت رقابتی عظیم است:اضافهکردن یک Partner یا شروع یک کمپین جدید فقط به تنظیمات وابسته است، نه توسعهٔ نرمافزار.III.2 محدودیتها و الزاماتی که معماری MaMa را شکل دادهانددر طراحی یک پلتفرم CRM در مقیاس ملی، محدودیتها نقشی تعیینکننده دارند.در MaMa، این Constraints جزو ستونهای اصلی معماری هستند.۱) محدودیتهای کلی معماریبدون برنامهنویسی، فقط با پیکربندی باید بتوان کمپین ساختاین مهمترین اصل معماری است:برای ساخت یا اجرای یک کمپین جدید، هیچ تغییری در کد نباید لازم باشد.هرچیز باید از طریق پیکربندی (فایل، UI یا ابزار اختصاصی) انجام شود.تکنولوژی پایه: JavaMaMa باید روی نسخههای جدید JVM قابل اجرا باشد (حداقل نسخه ۱.۶).تمام قابلیتها و توسعهها بر این اساس طراحی شدهاند.بانک اطلاعاتی اجباری: Oracleاین محدودیت به انتخاب تیم نبود؛Holding شرکت InDAC قرارداد سازمانی با Oracle داشت،بنابراین MaMa-CRM اجباری بود روی Oracle پیادهسازی شود.۲) محدودیتهای زیرساخت نرمافزارسیستمعامل: Linux (ترجیحاً RedHat Enterprise)به دلیل سختگیریهای امنیتی، نسخههای Hardened ردهت انتخاب اصلی بودند.استفاده از نرمافزارهای متنباز با لایسنس آزادGNU و FSF مجاز نبودند—در نتیجه انتخاب ابزارها کاملاً محدود میشد.ترجیح توسعه مبتنی بر Code Generation / مدلسازی MDSDتوسعه باید با حداقل کدنویسی و حداکثر تولید خودکار انجام شود.این موضوع بر ساختار لایه دامنه و مدل داده اثر جدی گذاشت.استفاده از ابزار مدلسازی (UML) توصیهشدهبه دلیل نیاز به مستندسازی سنگین، UML یکی از ابزارهای کلیدی تیم بود.توسعهٔ تدریجی (Iterative) توصیه میشوداما اجباری نبود؛ تیم آزادی عمل داشت تا روش مناسب خود را انتخاب کند.نیاز به مستندسازی فنی «عمیق و پایدار»InDAC تأکید داشت که:سیستم باید قابل نگهداری در درازمدت باشدمستندات باید واضح، بهروز، و دقیق باشندبه همین دلیل arc42 اساس کار قرار گرفت.۳) محدودیتهای عملیاتی (Operational Constraints)هر کمپین باید روی یک VM جداگانه اجرا شوداین الزام امنیتی باعث شد MaMa یک سیستم کاملاً Multi-Instance باشد.هیچ کمپینی نباید داده یا فرآیند کمپین دیگر را ببیند.اجرا به صورت Batch / Backgroundبیشتر پردازشها:زمانبر،دادهمحور،و شدیداً وابسته به شرکا هستند.بنابراین MaMa باید بدون رابط تعاملی،و صرفاً در حالت پردازش پسزمینه اجرا شود.تمام پیکربندیها باید از طریق یک افزونهٔ سفارشی Eclipse یا رابط وب قابل انجام باشدتیم InDAC به ابزاری نیاز داشت که بتواند:کمپین را ایجاد کندورودی/خروجیها را تنظیم کندقوانین را تعریف کندو تمام چیزها را بدون لمس Backend پیکربندی کنداین مورد تأثیر مستقیم روی طراحی UI و API داخلی MaMa داشت.III.3 محدودهٔ سیستم و تعاملات آن System Scope and ContextMaMa-CRM یک سیستم کاملاً «بین سازمانی» است.هر نمونه از MaMa برای یک Mandator و چندین Partner کار میکند.این یعنی هر instance دارای مجموعهای کاملاً مستقل از ورودیها، خروجیها، قوانین و تبادلات داده است.۳.۱ زمینه کسبوکار (Business Context)MaMa میان سه گروه داده جریان ایجاد میکند:۱) Mandator ↔ MaMaMandator دادههای اولیه کمپین را ارائه میکند، شامل:دادهٔ مشتریقراردادهاتعرفههاقوانین کمپینMaMa این داده را پردازش میکند و در پایان، نتیجه نهایی کمپین را به Mandator بازمیگرداند.تبادلات دادهٔ کلیدی شامل:Master Data (ورودی)وضعیت کمپین (خروجی دورهای)درخواستهای رفع ابهام(مثلاً وقتی آدرس غلط است، امضا ناقص است یا دادهٔ مشتری معتبر نیست)این دادهها کاملاً حساس هستند و باید طبق قانون حفاظت داده نگهداری شوند.۲) Partner ↔ MaMaPartnerها شامل:چاپاسکنOCRپستمرکز تماسفروشگاههاارائهدهندگان کارت سلامتهستند.دادههای رد و بدلشده:ارسال دادهٔ مشتری به Partner (Outbound)دریافت نتایج اولیه از Partner (Inbound)این دادهها شامل:اسکنهانتیجهٔ تماسهاوضعیت تحویل نامهلاگهای پردازشMaMa باید قبل از استفاده، نتایج را تحلیل و به وضعیت نهایی تبدیل کند.۳) اصل "Data Minimization"نکتهٔ بسیار مهم در معماری:هر Partner فقط دادهای را دریافت میکند که واقعاً نیاز دارد.مثلاً:مرکز تماس → فقط نام و شماره تماسسرویس چاپ → فقط آدرس و دادههای مربوط به نامهشرکت کارت → فقط تصویر و مشخصات لازم برای چاپ کارتاین اصل، هم امنیت را افزایش میدهد، هم ریسکهای قانونی را کاهش میدهد.۳.۱ زمینهٔ کسبوکار (نسخهٔ رسمی) – Formal Business Contextدر نسخهٔ رسمیتر از دیاگرام زمینهٔ کسبوکار MaMa-CRM، یک بخش مهم اضافه میشود: رابط مدیریت (Admin Interface).این رابط برای تیمهای MaMa و مدیران کمپینها ضروری است، زیرا تمام عملیات حیاتی سیستم از طریق آن انجام میشود:ایجاد یک کمپین جدیدپیکربندی قوانین، فعالیتها و جریان کارتعریف ورودی و خروجیهای دادهمدیریت کاربران و سطح دسترسیهانظارت بر وضعیت کمپین و کنترل عملیاتدر واقع، Admin Interface مغز کنترل MaMa است؛ بخشی که اجازه میدهد بدون تغییر کد، دهها کمپین مختلف برای دهها Mandator اجرا شود.در این دیاگرام رسمی (که در کتاب arc42 نمایش داده شده)، MaMa در مرکز قرار میگیرد و بهعنوان سیستم هماهنگکنندهٔ اصلی بین Mandator، Partnerها و مدیران سیستم عمل میکند.۳.۱.۲ زمینهٔ کسبوکار اختصاصی – سناریوی «اصلاح قرارداد موبایل»در بخش 1.1.1 یک نسخهٔ مفهومی از این سناریو ارائه شد. اما در اینجا ساختار دقیقتر و رسمیتری از تعامل سیستمها و جریان داده نمایش داده میشود.این سناریو یکی از پیچیدهترین نمونههای کمپین است، زیرا:چندین منبع دادهچند مقصد خروجیتبادلات چندمرحلهایفرآیندهای انسانی و ماشینیو قواعد پیچیده تجاریرا درگیر میکند.تصویر کلی سناریو:Mandator (اپراتور موبایل) دادهٔ مشتریان را بارگذاری میکند →MaMa داده را پردازش میکند →اطلاعات لازم به Partnerهای مختلف ارسال میشود (چاپ، اسکن، مرکز تماس…) →نتایج آنها به MaMa بازمیگردد →MaMa همه چیز را تفسیر کرده و نتیجهٔ نهایی را به Mandator برمیگرداند.جریانهای داده در سناریوی اصلاح قرارداد موبایل۱) دادهٔ ورودی از Mandator → به MaMa (Inbound)Mandator مجموعهای از اطلاعات پایه مشتری را ارسال میکند:نام، آدرس و اطلاعات تماساطلاعات قرارداد فعلیجزئیات تعرفهٔ فعلی و تاریخ اعتبارشناسهٔ مشتری و شمارهٔ قرارداداین دادهها معمولاً:در قالب CSVZip شدهو از طریق sftpبارگذاری میشوند.این انتقال دو بار انجام میشود:بار اول: هنگام شروع کمپینبار دوم: هنگام پاسخ به Clarification Requestهای MaMa۲) خروجی MaMa → به Mandator (Outbound)زمانی که MaMa تمام دادهها را پردازش کرد، نتیجهٔ نهایی را ارسال میکند:کدام مشتریان پیشنهاد جدید را پذیرفتهاندتغییرات لازم در قراردادتعرفهٔ جدید و تاریخ اعمال آناین خروجی نیز Zip و از طریق sftp ارسال میشود.MaMa همچنین درخواستهای رفع ابهام را نیز از همین مسیر ارسال میکند:دادهٔ ناقصآدرس اشتباهنبودن امضادادهٔ متناقض با قوانین کمپین۳) دادهٔ خروجی MaMa → به Print ProviderMaMa باید بخشهای مرتبط از داده را به سرویس چاپ ارسال کند:نامآدرسبخشهایی از اطلاعات قرارداد یا تعرفهبرای امنیت بیشتر:فایل CSV فشرده میشود (Zip)سپس PGP رمزگذاری میشودو از طریق HTTP Upload امن منتقل میشودنگاشت فیلدها و قالب دادههر Mandator و Partner فرمت مخصوص خود را دارد.بنابراین لازم است:برای هر Instance از MaMa، نگاشت دقیق فیلدهای داده به ستونهای CSV یا رکوردهای ثابت تعریف شود.این کار با استفاده از یک DSL اختصاصی انجام میشود(توضیح کامل این DSL در بخش ۸.۳ کتاب آمده است: CSV-Import/Export).این DSL به MaMa اجازه میدهد:بدون تغییر حتی یک خط کدساختار دادهٔ هر Mandator را تعریف و اعمال کندو ورودی و خروجیهای متعدد را مدیریت کنداین بخش یکی از دلایل کلیدی معماری «پلتفرم چندسازمانی» بودن MaMa است.۳.۱.۲ زمینهٔ کسبوکار اختصاصی: سناریوی «اصلاح قرارداد موبایل»این بخش نسخهٔ رسمیتر و فنیتر همان مثال فصل 1.1.1 است: کمپین تغییر تعرفهٔ یک اپراتور موبایل (MoPho).در این سناریو، MaMa-CRM نقش «ستون فقرات داده و فرآیند» را ایفا میکند و ارتباط میان Mandator، شرکای بیرونی، و مشتریان را هماهنگ میسازد.این سناریو دقیقاً نشان میدهد که چرا MaMa باید اینقدر انعطافپذیر، مقیاسپذیر و ایمن باشد.جریانهای داده در کمپین تغییر قرارداد موبایل۱) دادهٔ ورودی از Mandator → به MaMaMandator (اپراتور موبایل) برای شروع کمپین، اطلاعات کامل مشتریان را در اختیار MaMa قرار میدهد. این داده شامل:نام و نام خانوادگیآدرس کاملاطلاعات تماساطلاعات قرارداد فعلیتعرفهٔ فعلی و تاریخهای اعتبارکد مشتری یا شناسهٔ مشترکاین دادهها در دو موقعیت ارسال میشوند:در آغاز کمپینهنگام پاسخ به Clarification Requestهاقالب انتقالفایل CSVفشردهشده با Zipمنتقلشده از طریق sftpآپلود توسط خود Mandator۲) خروجی MaMa → به Mandatorپس از پردازش کامل دادهها و دریافت اطلاعات از Partnerها، MaMa نتیجهٔ نهایی را برای Mandator ارسال میکند.این نتایج شامل:وضعیت نهایی هر مشتریتعرفهٔ جدید انتخابشدهتغییرات لازم در قراردادتاریخ اعمال تغییرخروجی نیز مانند ورودی:CSVZip شدهاز طریق sftp ارسال میشودMaMa همچنین درخواستهای رفع ابهام (Clarification Requests) را نیز از همین مسیر ارسال میکند.۳) خروجی MaMa → به سرویس چاپ (Print Service Provider)برای ارسال نامههای پیشنهاد به مشتریان، MaMa بخشهای مرتبط از دادهها را به شرکت چاپ ارسال میکند:نام مشتریآدرس پستیبخشهای موردنیاز از اطلاعات قرارداد و تعرفهاما این انتقال از حساسترین بخشهای کمپین است.به همین دلیل:دادهها ابتدا Zip میشوندسپس با PGP رمزگذاری میشوندو نهایتاً از طریق HTTP Upload امن ارسال میگردنداینجا امنیت، محرمانگی و یکپارچگی داده نقش حیاتی دارند.نگاشت فیلدها: هر Mandator، زبانی متفاوت برای داده داردیکی از چالشهای اصلی MaMa این است که:هر Mandator و هر Partner قالب داده مخصوص خودش را دارد.برای همین، MaMa یک زبان DSL اختصاصی ارائه کرده است که با آن میتوان:فیلدهای مشتریستونهای CSVفرمت رکوردهاقواعد پردازش و اعتبارسنجیرا برای هر کمپین، بدون تغییر در کد، فقط از طریق پیکربندی تعریف کرد.این DSL ستون اصلی Data Flexibility در معماری MaMa است.توضیح فنی این DSL در بخش ۸.۳ کتاب آمده.۳.۲ زمینهٔ فنی و استقرار (Technical / Deployment Context)MaMa-CRM یک سیستم کاملاً multi-instance است؛ یعنی:برای هر Mandator، یک MaMa مستقل اجرا میشودهر کمپین، محیط مخصوص خود را داردهیچ دادهای نباید میان کمپینهای مختلف قابل مشاهده باشدبه همین دلیل معماری MaMa از پایه چند-نمونهای طراحی شده است.استقرار MaMa چگونه انجام میشود؟۱) هر MaMa instance روی یک ماشین مجازی جداگانه اجرا میشوددر حالت استاندارد:هر کمپین یک VM لینوکسی مستقل داردبانک اطلاعاتی آن نیز روی همان VM قرار داردارتباطات خارجی فقط از مسیرهای کنترلشده مجاز استدسترسی ssh تنها برای شبکه داخلی InDAC فعال استاما برخی Mandatorهایی که سطح امنیت بسیار بالایی میخواستند، اصرار داشتند:MaMa برای کمپین آنها باید روی یک سرور فیزیکی اختصاصی نصب شود.این موضوع به طور طبیعی هزینهٔ کمپین را افزایش میدهد.۲) سختافزار InDACتمام instanceها روی سرورهای سازمانی مستقر هستند:Dell، HP یا سختافزار مشابهسیستمعامل RHELمجهز به زیرساخت مجازیسازی (Hypervisor)۳) Mandator و Partnerبرای هر MaMa:یک Mandator وجود دارد (اپراتور موبایل، بیمه، بانک، انرژی و…)چندین Partner وجود دارد (چاپ، اسکن، مرکز تماس، پست، OCR و…)هر Partner یک کانال ارتباطی اختصاصی با MaMa دارد.این کانال میتواند:sftpftphttp(s)و حتی پروتکلهای سفارشیباشد.۴) بانک اطلاعاتی مستقلهر MaMa instance بانک اطلاعاتی Oracle خودش را دارد.چرا؟جداسازی امنیتیاستقلال عملیاتیامکان پاکسازی کامل دادهها پس از پایان کمپینپرهیز از درهمتنیدگی ساختار داده Mandatorهای مختلفIII.4 استراتژی راهحل (Solution Strategy)«چطور معماری MaMa کیفیتهای موردنیاز را تأمین میکند؟»در این بخش، MaMa-CRM توضیح میدهد که برای رسیدن به مهمترین نیازهای کیفی—بهخصوص Flexibility و Performance—از چه رویکردهای معماری استفاده شده است.این بخش عصارهای از تصمیمات کلیدی است؛ تصمیماتی که پایهٔ کل معماری MaMa را شکل میدهند.۱) انعطافپذیری در ساختار داده (Flexible Data Structure)یکی از چالشهای اصلی MaMa این است که هر Mandator ساختار دادهٔ مشتریان خود را دارد.راهحل معماری:ساختار پایگاه داده و کد persistence بهطور ۱۰۰٪ از مدل UML تولید میشود.یعنی:برای هر کمپین، یک مدل دامنه تعریف میشودکد و جدولهای پایگاه داده از آن مدل تولید میشوندبدون نیاز به دستکاری دستی، کد همیشه مطابق مدل بهروز استاین باعث میشود MaMa بتواند برای هر Mandator و هر کمپین، ساختاری متفاوت داشته باشد—بدون تغییر در منطق اصلی سیستم.۲) انعطافپذیری در فرمتهای ورودی/خروجی (CSV & Fixed-Length Files)MaMa باید داده را در فرمتهای مختلفی دریافت و ارسال کند.راهحل:یک زبان دامنهمحور (DSL) اختصاصی برای تعریف CSV و Fixed-Length ایجاد شده است.این DSL:ساختار هر فایلترتیب فیلدهاقواعد اعتبارسنجینحوهٔ تفسیر دادهرا بهصورت پیکربندی تعریف میکند.برای این DSL، تیم MaMa:یک Parser مبتنی بر ANTLR ساختهو Interpreterهای لازم را پیادهسازی کردهاین باعث شده اضافهکردن یک Partner جدید فقط به معنی ایجاد یک فایل DSL جدید باشد نه نوشتن کد جدید.۳) ایجاد Editor اختصاصی برای DSL (Eclipse Plugin)برای اینکه مدیران کمپین بتوانند بدون دانش فنی ساختار داده را تعریف کنند، MaMa یک ویرایشگر اختصاصی داخل Eclipse RCP ساخته است.این ویرایشگر:خطاها را در لحظه بررسی میکندساختار فایل و انواع داده را پیشنهاد میدهدامکان تولید خودکار mapping را فراهم میکنداین ابزار عملاً DSL را از یک ابزار توسعهای به یک قابلیت عملیاتی تبدیل کرده است.۴) کارایی بالا برای پردازش تصویر (Performance Strategy)در کمپینهایی مثل کارت سلامت، MaMa باید صدها هزار تصویر را پردازش کند.راهحل:تصاویر در پایگاه داده ذخیره نمیشوندبلکه روی فایلسیستم ذخیره میشوندبرای هر تصویر از Client-ID یک مسیر و نام یکتای قابل پیشبینی ساخته میشودتست بار (Load Testing) بخشی از CI شدهابزار تولید دادهٔ تست برای عملکرد ایجاد شدهاین تصمیم باعث شده MaMa بتواند:۲۵۰٬۰۰۰ تصویر را در کمتر از ۲۴ ساعت پردازش کند.III.5 نمای بلوکهای سازنده (Building Block View)«معماری MaMa از چه بخشهایی تشکیل شده و هر بخش چه نقشی دارد؟»نمای Building Block لایههای اصلی سیستم را توضیح میدهد.در سطح ۱ (Whitebox Level 1)، ما ساختار کلی MaMa را میبینیم—تقسیمشده بر اساس مسئولیتهای عملکردی.۵.۱ سطح سفید MaMa (Whitebox Level 1)معماری MaMa بر پایهٔ دو اصل ساخته شده است:Functional Decomposition → تقسیم سیستم به بخشهایی با مسئولیت مشخصGenerated Persistence → تولید کامل بخش داده بر اساس UMLدر این سطح، MaMa از چند بلوک اصلی تشکیل شده است:۱) Import Handler — ورودیگیر انعطافپذیراین ماژول وظیفه دارد:داده را از Mandator یا Partner دریافت کندفرمتهایی مثل CSV، Fixed-Length و XML را پردازش کنددادهٔ فشرده یا رمزگذاریشده را مدیریت کندخطاهای ارتباطی یا ساختاری را مدیریت کندویژگی کلیدی:پشتیبانی از کانالهای ورودی کاملاً پیکربندیپذیر.۲) Export Handler — ارسالکنندهٔ داده به شرکاکارها شامل:ارسال دادهٔ پردازششده به چاپ، اسکن، مرکز تماس یا Mandatorاعمال فیلترها و تبدیلهامدیریت رمزگذاری، فشردهسازی و اعتبارسنجیاین Handler مکمل Import Handler است و مشابه آن بر پایهٔ DSL عمل میکند.۳) Configuration — قلب پیکربندی کمپینهااین بخش مسئول تمام پیکربندیهای حیاتی است:قالب ورودی/خروجیکانالهای ارتباطیاطلاعات امنیتیقوانین کمپین (Campaign Rules)فعالیتها، فلوها و شرطهانگهداری و آرشیو دادهتنها با تغییر این بخش، میتوان یک کمپین کاملاً جدید ایجاد کرد.۴) Reporting — گزارشدهی وضعیت کمپینوظایف:تولید گزارشهای وضعیت برای Mandator و Partnerهانمایش پیشرفت کمپینارائهٔ گزارش فعالیتهای حساس مالی۵) Process Control — موتور اجرای کمپینمهمترین بخش MaMa:اجرای قوانین کمپینترتیب فعالیتهامدیریت Workflowزمانبندی عملیاتاجرای Import/Export بر اساس رویدادهاProcess Control چیزی شبیه «موتور جریان کار» (Workflow Engine) است.۶) Campaign Data Management — لایهٔ دادهٔ تولید شدهکاملًا:از روی UML تولید میشودمستقل برای هر کمپینشامل ساختار مشتری، قرارداد، فعالیتها و وضعیتها۷) Operations Monitoring — نظارت عملیاتیوظایف:مانیتورینگ Import و Exportنظارت بر دیتابیسمشاهدهٔ وضعیت کمپینمدیریت هشدارهااین ابزارهای نظارت برای مدیریت چندین کمپین همزمان حیاتی هستند.۸) Code Generator — قلب توسعهٔ سریعاین بخش بهصورت خودکار:ساختار DBکد persistenceentityهارا بر اساس مدل UML ایجاد میکند.این قابلیت یکی از نقاط قوت اساسی MaMa است.Import Handler — قلب ورودی داده در MaMa-CRMImport Handler یکی از حیاتیترین اجزای MaMa است؛ زیرا دقیقاً همان نقطهای است که دادهها از Mandatorها و Partnerها وارد سیستم میشوند.در کمپینهایی که میلیونها مشتری یا صدها هزار فایل اسکنشده وارد سیستم میشود، نحوهٔ مدیریت دادهٔ ورودی نقش تعیینکنندهای در کارایی و صحت کل کمپین دارد.Import Handler مسئول انجام سه کار کلیدی است:دریافت داده از طریق کانالهای مختلفاعمال پردازشهای لازم براساس فرمتها، فیلترها و رمزگذاریهاتبدیل دادهٔ خام به مدل دامنهٔ MaMa و ذخیرهٔ آنبه صورت خلاصه:Import Handler پلی میان دنیای نامنظم شرکای بیرونی و مدل دادهٔ دقیق MaMa است.مسئولیتها و قصد طراحیImport Handler میتواند:CSV،فایلهای Fixed-Length،یا XMLرا با ساختارهای قابل پیکربندی دریافت و پردازش کند.حتی اگر داده:فشرده شده،رمزگذاری شده،یا ترکیبی از این دو باشد،Import Handler آن را مدیریت میکند.این قابلیت به دلیل نیاز کمپینها به فرمتهای متنوع اطلاعات واقعاً حیاتی است.چگونه کار میکند؟ (Interfaces)شرح بلاگی از رفتار Import Handler:۱) خواندن تنظیمات Importپیش از هر چیز، Import Handler تنظیمات مخصوص کمپین را میخواند:ساختار CSVقوانین فیلتر (decrypt, unzip…)کانال انتقال (ftp، http، sftp)اطلاعات امنیتیاینکار باعث میشود Import Handler در هر کمپین رفتار متفاوتی داشته باشد—بدون هیچ تغییر در کد.۲) دریافت فایل یا داده از Mandator/PartnerImport Handler مستقیماً با محیط بیرونی تعامل دارد:اتصال به ftp یا sftpخواندن فایل از سیستم فایلدریافت داده از یک سرویس httpاین نقطهٔ تماس معماری با محیط خارج از سیستم است.۳) تبدیل داده به Client و ذخیره کردنپس از پردازش:دادههای خام تبدیل به آبجکتهای دامنه (Client, Contract…) میشوندسیستم با CampaginDataManagement تماس میگیرد تا این اطلاعات درج یا بهروزرسانی شوداین نقطهٔ اتصال ورودی به مدل دادهٔ داخلی MaMa است.مدیریت خطا: نقطهٔ قوت Import HandlerImport Handler مجموعهٔ قدرتمندی از مکانیسمهای مدیریت خطا دارد:خطاهای ارتباطی (شبکه، دسترسی، ftp…)خطاهای ساختار دادهخطاهای مربوط به فشردهسازیخطاهای رمزگشاییخطاهای رکوردهای ناسالمتقریباً همهٔ خطاهای سطح رکورد قابل بازیابیاند و فقط لاگ میشوند.فقط خطاهای بحرانی باعث توقف فرآیند میشوند.این طراحی به MaMa امکان میدهد با کیفیت دادهٔ بسیار متفاوت شرکا کنار بیاید.Configuration — موتور انعطافپذیری MaMaاگر Import Handler «دهان سیستم» باشد، Configuration مغز سیستم است.همهچیز در MaMa باید بدون برنامهنویسی قابل تغییر باشد؛ از جمله:قالبهای ورودی و خروجیمسیرها و پروتکلهای ارتباطیقوانین کمپینفعالیتها و ترتیب آنهانحوهٔ رمزگذاری/فشردهسازی دادههاConfiguration دقیقاً این کار را انجام میدهد.چه چیزهایی با Configuration کنترل میشود؟۱) تنظیمات Import/Exportشامل:CSVهای قابلپیکربندیfixed-length formatsXML-customendpointهای شبکهنوع رمزگذاری و فشردهسازیاطلاعات امنیتی برای اتصال به شرکا۲) تنظیمات کمپیندر هر کمپین نیاز است تعریف شود:چه فعالیتهایی وجود دارد؟ (Import, Export, Maintenance…)چه دادههایی الزامی هستند؟چه رویدادهایی باعث اجرای چه فعالیتی میشوند؟دادهها چه زمانی پاک/آرشیو میشوند؟این بخش یکی از حساسترین قسمتهای MaMa است.۳) قوانین نگهداری و آرشیومثلاً:حذف داده ۶۰ روز پس از پایان پردازشحذف کل دادهٔ کمپین ۱۲۰ روز پس از پایان رسمی کمپیننحوهٔ تعاملتمام فراخوانیهای Configuration باید با:campaignIDmandatorIDانجام شوند، زیرا هر کمپین کاملاً مستقل است.چیزی که مهم است:هیچ بخشی از سیستم بهطور مستقیم ساختار فایلها را نمیداند؛ همهچیز از Configuration میآید.این معماری باعث ایجاد استقلال شدید، و انعطافپذیری حداکثری میشود.MaMa Level 2 — ساختار Whitebox Import Handlerبرای مدیریت جریان ورودی داده، Import Handler به بخشهای داخلی مختلفی تقسیم شده است. این یک معماری pipeline-محور است:دریافت فایلفیلترها (decrypt/unzip)تقسیم رکوردهااعتبارسنجیتبدیل به آبجکتذخیرهسازیاجزای زیر این مراحل را انجام میدهند:Receiver — نقطهٔ ورود دادهوظیفهٔ Receiver:گوش دادن به پوشهها (Directory Listener)یا سرویسهای وبیا Listenerهای پیامReceiver اولین نقطهای است که داده وارد سیستم میشود.ImportErrorHandler — خطامدیری قدرتمنداین بخش:هر نوع خطا را شناسایی میکندخطاهای جدی را متوقف میکندخطاهای سطح رکورد را ثبت میکندبرای خطاهای قابلبازیابی، پردازش را ادامه میدهداین توانایی برای کار با دادههای ناسازگار از چندین Partner ضروری است.ImportData Port — اتصال به بیروناین مؤلفه مستقیماً با سیستمهای خارجی صحبت میکند:ftphttpVPNاین دقیقاً "دروازهٔ ارتباطی MaMa" است.FileArchiver — آرشیو غیرقابل حذفتمام فایلهای ورودی باید برای ممیزی ذخیره شوند.این آرشیو:غیرقابل حذفقابل بازرسیو مستقل از فرایند Importاست.FileFilter — لایهٔ فیلترهای پردازششامل:decryptunzipdecompressionو هر فیلتر دیگری که در DSL تعریف شوداین همانجاست که قالب فایل به حالت استاندارد تبدیل میشود.Validator — اعتبارسنج دادهاز سطح فایل تا سطح رکورد، Validator بررسی میکند:فرمت داده درست باشدمقادیر با قوانین کمپین سازگار باشنداشیاء ساختهشده معتبر باشندUnMarshaller — تبدیل رشته به آبجکتیکی از بخشهای جادویی MaMa.با استفاده از Reflection:خطوط و رکوردهای فایل تبدیل به آبجکتهای دامنه (Client, Contract…) میشوند.این بخش پیچیده است، اما ستون اصلی سیستم هنگام ورود داده است.MaMa Level 3 — جزئیات داخلی ReceiverReceiver خود به چند بخش تقسیم میشود:لایهی Directory/WebService/Message Listenerاین لایه:ورود فایلها را زیر نظر داردپوشههای محلی یا ریموت را مانیتور میکندپیامها یا سرویسهای وب را گوش میدهدReceiver بسته به کمپین، متفاوت پیکربندی میشود.FileProcessor — قلب جریان ورودیاین بخش:فایل را unzip میکندdecrypt میکندآن را آرشیو میکندرکوردها را جدا میکندو همهٔ فیلترها را اعمال میکنددر کتاب اشاره شده:«کد آن شبیه اسپاگتی است!»اما در عمل، این بخش حجم اصلی پردازش خام ورودی را انجام میدهد.مولفه FileToRecordSplitterاین مؤلفه:فایل را به رکوردهای منطقی تبدیل میکندمعمولاً هر خط = یک رکورد استاما در برخی فرمتها چند خط یک رکورد را تشکیل میدهنداین بخش کاری شبیه parsing اولیه انجام میدهد.III.6 نمای زمان اجرا (Runtime View)«MaMa در عمل چگونه کار میکند؟»تا اینجا معماری MaMa-CRM را بهصورت ایستا دیدیم: کامپوننتها، مسئولیتها و ساختار کلی.اما Runtime View نشان میدهد که این اجزا در زمان اجرا چگونه با هم تعامل میکنند و یک سناریوی واقعی را به پایان میرسانند.یکی از مهمترین و پرتکرارترین سناریوها در MaMa، وارد کردن فایل (Import File) است.6.1 سناریوی Import Fileفایلهای ورودی میتوانند از طرف Mandator یا Partner ارسال شوند، اما یک ویژگی مشترک دارند:همهٔ آنها حاوی دادههای مرتبط با Client هستندو در قالبهایی مانند CSV، Fixed-Length یا XML میآیند.معماری MaMa این سناریو را عمداً به دو فاز جدا تقسیم کرده است:Import Raw File (دریافت و آمادهسازی فایل خام)Validate & Process (اعتبارسنجی و بهروزرسانی دیتابیس داخلی)این جداسازی باعث میشود سیستم هم مقاومتر باشد، هم قابلگسترشتر.6.1.1 فاز اول: Import Raw File (پردازش خام و عمومی)در این فاز، هیچ قانون کمپینی اجرا نمیشود.هدف فقط این است که فایل:سالم دریافت شودامن ذخیره شودو به شکل قابل پردازش تبدیل گرددگامهای اصلی این فاز به ترتیب اجرا:۱) شروع Import توسط Process Controlفرآیند Import با یک شناسه یکتا آغاز میشود که شامل:MandatorCampaignActivityاست. این شناسه بعداً برای ردیابی، گزارش و ممیزی استفاده میشود.۲) دریافت تنظیمات ImportMaMa تمام تنظیمات لازم را از Configuration میگیرد:کانال دریافت (ftp, http, …)قالب فایلفیلترهای لازم (decrypt, unzip, …)هیچ چیزی hardcode نیست.۳) آمادهسازی کانال دریافت (configureReceiveChannel)در این مرحله، اتصال به دنیای بیرون شکل میگیرد:URLنام فایلاعتبارنامههامسیرهای دسترسی۴) آرشیو فایل خام (Archive)قبل از هر پردازشی، فایل خام وارد آرشیو غیرقابل حذف میشود.این آرشیو معمولاً write-once است و برای اهداف قانونی و ممیزی نگهداری میشود.این تصمیم معماری، نقش حیاتی در قابلیت audit سیستم دارد.۵) ساخت زنجیره فیلترها (instantiateFilterChain)بر اساس پیکربندی، یک pipeline از فیلترها ساخته میشود؛ مثلاً:unzipdecryptverify checksum۶) اجرای فیلترها (pipes-and-filters)فایل از این زنجیره عبور میکند تا به دادهای «خوانا و امن» تبدیل شود.این طراحی از الگوی Pipes & Filters استفاده میکند و کاملاً پویا و قابل پیکربندی است.6.1.2 فاز دوم: Validate & Process (اعتبارسنجی داده)پیشنیاز:فایل باید سالم دریافت، decrypt و decompress شده باشد.در این مرحله:دادهها بررسی میشوندرکوردهای معیوب شناسایی میشونددادههای معتبر وارد سیستم میشوندنکتهٔ مهم اینجاست:مدیریت خطا فقط در صورت بروز مشکل فعال میشوددر حالت ایدهآل، ImportErrorHandler اصلاً فراخوانی نمیشود.اما اگر خطایی رخ دهد:خطاهای بحرانی → توقف پردازشخطاهای سطح رکورد → ثبت، گزارش و ادامهٔ کاراین طراحی باعث میشود MaMa بتواند با دادههای «واقعیِ دنیای واقعی» کنار بیاید.III.7 نمای استقرار (Deployment View)«MaMa کجا و چگونه اجرا میشود؟»7.1 نمای کلی استقراراز همان ابتدای طراحی، یک اصل غیرقابل مذاکره وجود داشت:هر کمپین MaMa باید روی یک ماشین مجازی اختصاصی اجرا شود.دلایل این تصمیم:جداسازی کامل دادهٔ Mandatorهاافزایش امنیتسادهسازی ممیزی و حذف دادههاپیکربندی سیستمعامل، VM و Host تأثیر مستقیمی روی امنیت کمپین دارد و باید بهطور منظم بررسی شود.به دلیل حساسیت دادهها، جزئیات امنیتی در این مستند عمداً افشا نشدهاند.7.2 ماشین مجازی اختصاصی برای هر کمپینبرای هر کمپین:یک VM مجزا وجود داردیک دیتابیس اختصاصیکل کد MaMa (بهجز UI پیکربندی)هیچ اشتراکی در سطح داده یا پردازش وجود ندارد.این طراحی هزینه را بالا میبرد، اما امنیت و شفافیت را تضمین میکند.7.3 مخزن متادیتای مشترک (Common Metadata Store – CoMeS)در پروژهٔ کارت سلامت آلمان، یک چالش خاص وجود داشت:تولید Common Insurance ID (CID).CID فقط میتوانست توسط یک نهاد دولتی تولید شود و هر درخواست باید شامل:شناسه سازمان درخواستکنندههدف درخواستیک شماره ترتیبی بدون هیچ وقفه (RSN)مشکل کجا بود؟MaMa روی چندین VM مستقل اجرا میشد،اما RSN باید کاملاً پیوسته و هماهنگ میبود.راهحل معماری:ساخت یک Common Metadata Store اختصاصیبدون استفاده از دیتابیس عمومیبا تمرکز بر همگامسازی امن و قابل اعتماداین یک مثال عالی از تصمیم معماری کاملاً زمینهمحور است.7.4 ماشین پیکربندی کمپینپس از استقرار VMها، اپراتورها نیاز دارند کمپین را پیکربندی کنند.این کار از طریق:یک یا چند Workstation استانداردبا UI مبتنی بر Eclipse RCP Pluginانجام میشود.این UI امکان:تعریف کمپینتنظیم ورودی/خروجیقوانینفعالیتهارا بدون دست زدن به Backend فراهم میکند.III.8 مفاهیم سرتاسری (Cross-Cutting Concepts)«تصمیمهایی که در تمام MaMa حضور دارند»مفاهیم سرتاسری در arc42 به آن دسته از ایدهها و الگوهایی گفته میشود که:فقط به یک ماژول خاص محدود نیستنددر چندین بخش از سیستم تکرار میشوندو بهشدت روی معماری، توسعه و نگهداری سیستم اثر میگذارنددر MaMa-CRM، این مفاهیم ستون فقرات معماری را تشکیل میدهند. مهمترین آنها عبارتاند از:persistence تولیدشده از مدل دامنهDSL برای فرمت دادهفیلترهای قابل پیکربندیموتور قوانین برای کنترل فرآیند8.1 Persistence تولیدشده بر اساس مدل دامنه (Generated Persistence)یکی از جسورانهترین و در عین حال هوشمندانهترین تصمیمات معماری MaMa این است که:تمام کد مربوط به persistence (ذخیرهسازی داده) بهصورت خودکار از روی مدل UML تولید میشود.یعنی:هیچ جدول دیتابیسی بهصورت دستی نوشته نمیشودهیچ entity یا repository بهصورت دستی ساخته نمیشودهمهچیز از مدل دامنه استخراج میشوداین رویکرد باعث میشود انعطافپذیری MaMa در سطح داده به حداکثر برسد.چرا این کار منطقی بود؟ (پیشفرضهای معماری)این تصمیم بر اساس چند واقعیت دامنهای گرفته شد:هر MaMa instance با دادهٔ اشخاص حقیقی (Client) سروکار داردهمهٔ Clientها تعدادی ویژگی مشترک دارندهر Mandator ویژگیهای اختصاصی خودش را اضافه میکندبعضی کمپینها انواع دادهٔ کاملاً جدید دارند (مثل قرارداد بیمه یا قرارداد موبایل)ساختار داده پس از شروع کمپین تقریباً هرگز تغییر نمیکندنکتهٔ جالب:در چند سال کار عملی MaMa، هیچوقت نیاز به migration دیتابیس در یک کمپین فعال پیش نیامد.8.1.1 مدل دامنهٔ عمومی (MaMa Core Domain)در قلب MaMa یک مدل دامنهٔ عمومی وجود دارد که همهٔ کمپینها از آن استفاده میکنند.این مدل شامل مفاهیم پایهای است، از جمله:Client: یک کلاس انتزاعی که نمایندهٔ یک شخص و اطلاعات تماس اوستContact: اطلاعات ارتباطی که در طول کمپین استفاده میشودNext Action: نمایشدهندهٔ فعالیت بعدی در جریان کمپیناین مدل «هستهٔ مشترک» همهٔ کمپینهاست.8.1.2 مدل دامنهٔ اختصاصی کمپینهر کمپین، علاوه بر Core Domain، یک کپی فیزیکی از آن را به همراه توسعههای اختصاصی خودش دارد.در این مدلها:Client همیشه subclass میشودروابط جدید اضافه میشوندموجودیتهای اختصاصی دامنه (مثلاً InsuranceContract یا MobileContract) تعریف میشونداین یعنی هر کمپین:مدل دادهٔ خودش را دارد، اما روی یک هستهٔ مشترک سوار شده است.8.1.3 جزئیات Code Generatorبرای تولید persistence، MaMa از ابزارهای زیر استفاده میکند:OpenArchitectureWare (OAW) برای تولید کدHibernate برای ORM و persistenceکد تولیدشده شامل موارد زیر است:DDL کامل دیتابیس (schema، جدولها، indexها)فایلهای mapping هابرنیتمتدهای campaign-specific برای جستوجو و پردازشمتدهای گزارشگیری و مانیتورینگمحدودیتها:ارتباطهای m:n پشتیبانی نمیشوندتغییر ساختار داده در کمپین فعال مجاز نیستبه دلیل قراردادهای عدم افشا، نمونه کد قابل انتشار نیست.چرا این ابزار انتخاب شد؟ (Alternative Analysis)MaMa ابتدا از AndroMDA استفاده میکرد، اما پروژه عملاً متوقف شدMagicDraw امکان تولید کد داشت، اما برای Hibernate بیش از حد محدود بوددر نهایت OAW بهترین توازن بین انعطافپذیری و کنترل را فراهم کرد8.2 Import / Export CSV (نگاه کلی)در MaMa، CSV فقط یک فرمت ساده نیست؛بلکه بخشی از یک زبان دامنهمحور (DSL) است که تعریف میکند:فیلدها چه هستندترتیبشان چیستچگونه اعتبارسنجی میشوندو چطور به مدل دامنه نگاشت میشوندبرای این DSL:Parser اختصاصی نوشته شدهEditor سفارشی در Eclipse ساخته شده(جزئیات کاملتر در نسخهٔ اصلی کتاب آمده است.)8.3 فیلترهای فایل قابل پیکربندی (Configurable File Filters)هر فایلی که از بیرون وارد MaMa میشود، باید از یک زنجیرهٔ فیلتر عبور کند.این دقیقاً همان چیزی است که در Runtime View دیدیم.دو نوع فیلتر اصلی وجود دارد:۱) فیلترهای رمزنگاری (Encryption Filters)سازگار با Java Cryptography Architectureقابل استفاده با Providerهایی مثل BouncyCastleنیازمند کلید، certificate یا credentialبه دلیل حساسیت دادهها، جزئیات پیادهسازی امنیت منتشر نشده است.۲) فیلترهای فشردهسازی (Compression Filters)فقط الگوریتمهای بدون اتلاف (Lossless)مثل DEFLATE (zip / gzip) یا Lempel-Zivبدون پارامتر پیچیدهاین فیلترها بهصورت زنجیرهای و پویا پیکربندی میشوند.8.4 موتور قوانین برای کنترل فرآیند (Rule Engine)یکی از تفاوتهای اساسی MaMa با CRMهای سنتی، استفاده از Rule Engine واقعی است.8.4.1 جریان اقدام (Flow of Action)رفتار کمپینها با قوانین تعریف میشود، نه با if/elseهای سختکد شده.این یعنی:تغییر رفتار بدون redeployامکان تنظیم سریع کمپینجداسازی منطق کسبوکار از کد8.4.2 Drools بهعنوان Rule EngineMaMa از Drools (متنباز) برای تعریف و اجرای قوانین استفاده میکند.ویژگیهای کلیدی:قوانین بهصورت فایل متنی تعریف میشونددر زمان اجرا تفسیر میشوندبدون نیاز به کامپایل کل سیستمقالب قوانین بسیار ساده است:when then که در آن A و B عبارات جاوایی هستند.⚠️ نکتهٔ مهم معماری:قوانین اشتباه میتوانند یک کمپین فعال را مختل کنند؛به همین دلیل تست قوانین قبل از اجرا الزامی است.III.9 تصمیمات معماری (Architecture Decisions)«چند تصمیم کلیدی که سرنوشت MaMa را ساخت»هر سیستم بزرگ، چند تصمیم دارد که اگر اشتباه گرفته شوند، کل محصول را زمین میزنند.در MaMa-CRM هم چند تصمیم خیلی تعیینکننده وجود داشت؛ تصمیمهایی که مستقیماً از نیازهای کیفیتی سیستم (خصوصاً انعطافپذیری و کارایی) آمدهاند.۱) استفاده نکردن از ابزارهای CRM تجاریتیم MaMa از همان ابتدا تصمیم گرفت هیچ CRM تجاری آمادهای را بهعنوان پایهٔ سیستم انتخاب نکند.دلیلش ساده ولی حیاتی بود:سطح انعطافپذیری موردنیاز برای راهاندازی سریع کمپینها، با معماری CRMهای آماده سازگار نبود.این تصمیم بعداً ثابت کرد درست بوده؛ چون رقبای اولیهای که سعی کردند با «کمی دستکاری» روی CRMهای استاندارد وارد این بازار شوند، عملاً شکست خوردند و نتوانستند وارد فضای عملیاتی شوند که MaMa در آن کار میکرد.۲) انتخاب JBoss Drools برای پردازش قوانینMaMa برای کنترل منطق کمپینها و تصمیمگیریهای فرآیندی، به یک Rule Engine واقعی نیاز داشت. انتخاب نهایی:JBoss Droolsتیم گزینهٔ دیگری مثل Python/Jython را هم بررسی کرد، اما نتیجه واضح بود:برای نوع پردازش MaMa، Jython بیش از حد کند بودDrools هم سریعتر بود و هم برای مدل «قوانین قابل تغییر در زمان اجرا» مناسبتراین تصمیم کاملاً با نیاز انعطافپذیری و تغییر سریع قوانین کمپین همراستا بود.۳) عدم استفاده از ابزار ETL برای Import دادهخیلیها در چنین سیستمهایی سراغ ETL میروند؛ اما MaMa این کار را نکرد.علت اصلی، فنی نبود؛ اقتصادی و سازمانی بود:شرکت InDAC حاضر نشد هزینهٔ لایسنس ابزارهای ETL تجاری را بپذیرد،پس تیم حتی فرصت ارزیابی جدی آنها را هم نداشت.در نتیجه Import/Export در MaMa بهصورت داخلی و با DSL و pipelineهای قابل پیکربندی ساخته شد—که البته در نهایت به انعطافپذیری بالاتری هم منجر شد، ولی با هزینهٔ پیچیدگی توسعه.III.10 نیازمندیهای کیفی (Quality Requirements)«کیفیت یعنی چیزی که قابل اندازهگیری باشد»MaMa فقط نمیگوید “سیستم باید منعطف باشد”.این سیستم کیفیت را به سناریوهای عملیاتی تبدیل کرده؛ یعنی چیزی که بتوان با آن تست کرد، سنجید و الزام ایجاد کرد.سناریوهای انعطافپذیری (Flexibility Scenarios)هدف اصلی این سناریوها این است که MaMa بتواند بدون برنامهنویسی و در زمان کوتاه، فرمتها را تغییر دهد یا فرمت جدید اضافه کند.در MaMa معیار مشخص است:هر فرمت جدید باید در زمان پیکربندی کمپین (CCT) و حداکثر ظرف ۲ ساعت قابل راهاندازی باشد.این الزام برای همهٔ حالتها تعریف شده است:اضافه کردن فرمت جدید برای Import از نوع CSVاضافه کردن فرمت جدید برای Import از نوع Fixed-Fieldاضافه کردن فرمت جدید برای Import از نوع XMLاضافه کردن فرمت جدید برای Export از نوع CSVاضافه کردن فرمت جدید برای Export از نوع Fixed-Fieldاضافه کردن فرمت جدید برای Export از نوع XMLو یک شرط جدی هم دارد:مستند فرمت باید وجود داشته باشدحداقل ۱۰ رکورد دادهٔ تست متنوع باید ارائه شوداین یعنی انعطافپذیری «شعاری» نیست؛ یک قرارداد عملیاتی دقیق است.سناریوهای کارایی زمان اجرا (Runtime Performance Scenarios)MaMa باید در مقیاس واقعی کار کند. دو الزام اصلی عملکرد:پردازش کامل ۲۵۰٬۰۰۰ سند اسکنشده در ۲۴ ساعتاین شامل:CSVو تصاویر به صورت فایلهای جدااست.اگر بخواهیم به زبان ساده تبدیلش کنیم:یعنی سیستم باید به طور متوسط حدود ۳ سند کامل در ثانیه را از ابتدا تا انتها پردازش کند.پردازش کامل ۱۰۰٬۰۰۰ رکورد CSV در کمتر از ۳۰ دقیقهاین یعنی تیم معماری از ابتدا پذیرفته که “کمپینها حجیماند” و سیستم باید روی throughput طراحی شود.سناریوهای امنیت (Security Scenarios)سه الزام امنیتی کلیدی:جداسازی کامل دادهها بین Mandatorهاهیچ دادهای از یک Mandator نباید برای Mandator دیگر قابل دسترس باشد. این همان دلیل VM و DB جداگانه برای هر کمپین است.قابلیت ممیزی سریع دادههای آرشیویMaMa موظف است تمام دادههای ورودی (فایلها/پیامها) را برای بازهٔ زمانی مشخص (معمولاً ۹۰ تا ۱۸۰ روز پس از پایان کمپین) نگه دارد.و اگر ممیز بخواهد، سیستم باید:حداکثر ظرف ۹۰ دقیقه همهٔ دادههای آرشیو را قابل دسترسی کند.انطباق با PCI-DSS در صورت وجود دادهٔ مالیاگر کمپینی اطلاعات بانکی/کارت اعتباری داشته باشد، پردازش و نگهداری باید مطابق PCI-DSS انجام شود.III.11 ریسکها (Risks)«چیزهایی که اگر اصلاح نشوند، دیر یا زود ضربه میزنند»این بخش از آن قسمتهایی است که تیم معماری واقعاً شفاف حرف زده—و این دقیقاً همان چیزی است که arc42 دوست دارد: واقعیت، نه تبلیغ.۱) Receiver یک نقطهٔ درد مزمن استکامپوننت Receiver به دلیل اینکه در طول زمان توسط چند توسعهدهنده و بدون هماهنگی رشد کرده، بیش از حد پیچیده و درهم شده است.نتیجه عملی:از همان روزهای اول، بیشتر باگهای پروداکشن از همین بخش آمدهاند.این یعنی Receiver از نظر معماری «نیاز به بازطراحی یا refactor سنگین» دارد.۲) انعطافپذیری زیاد، ریسک رفتار اشتباهاین سیستم عمداً runtime-configurable است. ولی یک مشکل بزرگ دارد:هیچ بررسی/اعتبارسنجی جدی برای پیکربندیها وجود نداردپس ممکن است:سیستم اشتباه کار کندو این اشتباه حتی دیر تشخیص داده شودبدتر از آن:یک ادمین بدخواه میتواند هر لحظه سیستم را misconfigure کند.۳) پیکربندیها آرشیو نمیشوندیکی از خطرناکترین ریسکها:تنظیمات کمپینها نسخهبندی و آرشیو نمیشوندممکن است تنظیمات درست گم شوندو هیچ راه برگشتی به “آخرین پیکربندی سالم” وجود نداشته باشدبرای سیستمی که همه چیزش configuration است، این یک ضعف جدی است.۴) Common Metadata Store ناکارآمد استCoMeS یک راهحل ساده و سریع برای همگامسازی RSN بود، ولی مشکلاتش واضح است:ساده و ابتدایی استمنابع را هدر میدهدو باید سریعاً با یک سیستم درستتر جایگزین شودپیشنهاد خود متن هم روشن است:بهتر است با یک مکانیزم async / event-based جایگزین شود.سخن پایانیبا رشد سیستمهای سازمانی پیچیده، برونسپاری فرآیندها، کمپینهای دادهمحور و معماریهای منعطف مبتنی بر پیکربندی، داشتن یک مستند معماری شفاف و استاندارد دیگر یک گزینهٔ لوکس نیست؛ یک ضرورت عملیاتی است. نمونهای مثل MaMa-CRM نشان میدهد که arc42 فقط برای سیستمهای آموزشی یا کوچک نیست، بلکه میتواند ستون فقرات مستندسازی معماری سامانههای بزرگ، حساس و چندسازمانی باشد—از CRMهای مبتنی بر کمپین گرفته تا پلتفرمهای دادهمحور در مقیاس ملی.arc42 کمک میکند تصمیمات معماری، نیازمندیهای کیفی، محدودیتها، ریسکها و منطق طراحی سیستم بهصورت ساختیافته، قابل فهم و قابل انتقال مستند شوند؛ بهگونهای که هم تیم فنی، هم ذینفعان غیر فنی و هم تیمهای آینده بتوانند به یک درک مشترک برسند. همین شفافیت است که نگهداری، توسعه و تکامل سیستم را در بلندمدت ممکن میکند.اگر در پروژههای خود با چالشهایی مثل پیچیدگی معماری، نبود مستند قابل اتکا، یا نیاز به استانداردسازی طراحی سیستم مواجه هستید، تیم معماری و توسعهی نرمافزار شرکت راهکار نگار هوشمند (آرکان) میتواند از تحلیل معماری موجود تا تدوین مستند arc42 و همراهی در پیادهسازی عملی، کنار شما باشد.این مقاله با هدف آگاهیبخشی و انتقال تجربهی معماری، توسط تیم توسعهی نرمافزار شرکت راهکار نگار هوشمند (آرکان) تهیه شده است.#معماری_نرمافزار#arc42#مستندسازی_معماری#CRM#enterprise_architecture#تحلیل_سامانه#طراحی_سیستم#معماری_فنی#Software_Architecture#architecture_documentation#distributed_systems#quality_attributes#technical_writing#شرکت_راهکار_نگار_هوشمند#arcanco

تحلیل و مستندسازی معماری ابزار HSC بر اساس arc42

محمد حسین جلیلی — Mon, 08 Dec 2025 23:27:43 +0330
در ادامه‌ی مسیرمان برای یادگیری و تمرین عملی الگوی مستندسازی arc42، حالا زمان آن رسیده که از یک سیستم واقعی کمک بگیریم؛ سیستمی که به اندازه‌ی کافی کوچک باشد تا بتوانیم تمام بخش‌های معماری‌اش را تحلیل کنیم، اما به‌قدری کاربردی باشد که مثال‌ها و تصمیم‌های معماری‌ آن واقعی و قابل لمس باشند.در میان مثال‌های موجود، ابزار HTML Sanity Check (HSC) یکی از بهترین گزینه‌هاست.HSC یک ابزار متن‌باز کوچک است که روی فایل‌های HTML «سلامت‌سنجی» انجام می‌دهد—یعنی لینک‌های خراب، تصاویر گم‌شده، منابع محلی وجود‌نداشته، alt-tagهای ناقص و ده‌ها اشکال رایج دیگر را شناسایی می‌کند.این ابزار معمولاً زمانی استفاده می‌شود که صفحات HTML از ابزارهایی مانند Asciidoctor یا Markdown تولید می‌شوند؛ جایی که تبدیل‌کننده‌ها مسئولیت بررسی کیفیت خروجی را برعهده نمی‌گیرند و این خطاها معمولاً تا زمان انتشار پنهان می‌مانند.اما دلیل ما برای انتخاب این ابزار فقط کارکردش نیست.HSC در کتاب "arc42 by Example" به‌عنوان یک نمونه‌ی رسمی برای مستندسازی معماری استفاده شده است.این یعنی ساختار، تصمیم‌های فنی، زیرسیستم‌ها، آداپتورها، کیفیت‌ها و ریسک‌هایش به‌خوبی قابل تحلیل و تبدیل به یک سند arc42 هستند.در این مقاله، ابتدا این سیستم را معرفی می‌کنیم تا مشخص شود HSC دقیقاً چه می‌کند، از چه بخش‌هایی تشکیل شده، و چه نوع چک‌هایی انجام می‌دهد. پس از آن، در بخش‌های بعدی وارد دنیای arc42 می‌شویم و گام‌به‌گام سند معماری این ابزار را مطابق با سرفصل‌های arc42 بازسازی و تحلیل می‌کنیم.اگر قصد داری معماری نرم‌افزار را به‌صورت حرفه‌ای یاد بگیری یا می‌خواهی بفهمی مستندات arc42 در عمل چه شکلی دارند، HSC بهترین نقطه‌ی شروع است.II.1 مقدمه و اهداف سیستم (HTML Sanity Check – HSC)در این بخش از مستند arc42، معمولاً توضیح داده می‌شود که چرا این سیستم ساخته شده و چه نیازهایی آن را شکل می‌دهند. هدف اصلی این قسمت، این است که ذینفعان بتوانند قبل از ورود به جزئیات فنی معماری، تصویر روشنی از مسئله، هدف و ارزش سیستم به‌دست آورند.برای مثال HTML Sanity Check (HSC)، این بخش نقش مهم‌تری دارد؛ چون HSC یک ابزار کوچک اما چندمنظوره است که در سناریوهای متفاوتی (CLI، Gradle، Maven، کتابخانه) استفاده می‌شود و لازم است پیش از بررسی معماری‌اش بفهمیم قرار است چه مسئله‌ای را حل کند.محتوا و انگیزه ساخت سیستمنقطه‌ی آغاز HSC، چالش رایجی است که نویسندگان و مستندسازان دیجیتال با آن مواجه می‌شوند:وقتی خروجی HTML از ابزارهایی مثل Asciidoctor یا Markdown تولید می‌شود، اغلب هیچ تضمینی درباره‌ی صحت و کیفیت لینک‌ها، تصاویر، IDها و منابع وجود ندارد.بنابراین HSC با هدف اصلی زیر طراحی شد:پشتیبانی از نویسندگان محتوا با بررسی خودکار لینک‌ها، تصاویر و منابع داخل فایل‌های HTML و تولید گزارش شفاف از خطاهای موجود.این ابزار یک sanity checker است؛ یعنی کاری می‌کند که HTML تولید شده از نظر معنا و ساختار (Semantic Integrity) بررسی شود، نه فقط از نظر شکل ظاهری.۱.۱ نمای کلی نیازمندی‌هاپیش از ورود به معماری، لازم است فهم دقیقی از کارکردهای اصلی سیستم داشته باشیم.این بخش به خواننده کمک می‌کند «وظیفه اصلی HSC چیست» را بفهمد.هدف کلیدی سیستمتولید گزارش‌های دقیق، تمیز و قابل‌فهم از خطاهای HTML.این گزارش‌ها می‌توانند مشابه گزارش‌های تست واحد (unit test reports) باشند و شامل:لینک‌های شکستهتصاویر گم‌شدهمنابع محلی ناپیداتکرار IDهالینک‌های خارجی خرابمشکلات syntax و ساختاربرای مثال، نویسندگان معمولاً این مسیر را طی می‌کنند:نوشتن متن در AsciiDoc یا Markdownدریافت HTML نهایی توسط ابزارهای تبدیلاستفاده از HSC برای بررسی خروجی HTMLدریافت گزارش مشکلاتsemanticاین جریان، فلسفه‌ی وجودی HSC را تعریف می‌کند.سناریوهای پایه‌ی استفادهبرای درک بهتر سیستم، رفتار HSC را در ابتدایی‌ترین حالت مرور کنیم:کاربر مسیر چند فایل HTML یا پوشه مربوطه را تنظیم می‌کند.ابزار مجموعه‌ای از چک‌ها را روی فایل‌ها اجرا می‌کند.نتیجه را یا در کنسول نمایش می‌دهد یا یک گزارش HTML تولید می‌کند.HSC می‌تواند از طریق CLI یا Gradle اجرا شود، و این تنوع در روش استفاده، بعدها روی ساختار معماری سیستم نیز تأثیر می‌گذارد.نیازمندی‌های اصلی سیستم (Goals)برای اینکه بتوانیم معماری HSC را درست تحلیل کنیم، باید ابتدا اهداف و نیازمندی‌های اصلی سیستم را بشناسیم. این نیازمندی‌ها مشخص می‌کنند که HSC در اصل برای انجام چه کارهایی طراحی شده و معماری آن باید چه قابلیت‌هایی را پشتیبانی کند.۱) بررسی خطاهای معنایی HTMLهسته‌ی اصلی HSC این است که فایل‌های HTML را از نظر semantic integrity بررسی کند؛ یعنی بتواند مشکلاتی مثل لینک‌های داخلی شکسته، تصاویر گم‌شده یا منابع ناپیدا را شناسایی کند.۲) قابل اجرا بودن به‌عنوان پلاگین Gradle و MavenHSC باید قابلیت یکپارچه‌سازی در فرآیند ساخت پروژه را داشته باشد. بنابراین لازم است به‌عنوان پلاگین Gradle و پلاگین Maven قابل اجرا باشد تا تیم‌های مختلف بتوانند آن را در ساختار CI/CD خود قرار دهند.۳) پشتیبانی از چندین فایل ورودی در یک اجراکاربر باید بتواند به‌جای یک فایل HTML، مجموعه‌ای از فایل‌ها یا یک پوشه کامل را به ابزار بدهد. HSC باید همه آن‌ها را در یک مرحله پردازش و یک گزارش واحد و تجمیع‌شده تولید کند.۴) ارائه پیشنهاد برای رفع خطاهاوقتی HSC خطایی را پیدا می‌کند، فقط گزارش آن کافی نیست؛ باید بتواند پیشنهاد یا سرنخی برای رفع خطا ارائه دهد. مثلاً اگر لینک شکسته است، مقادیر مشابه یا اشتباه تایپی ممکن را پیشنهاد کند.۵) پیکربندی‌پذیری بالارفتار سیستم باید قابل تنظیم باشد.کاربر باید بتواند:مسیر فایل‌هامسیر خروجی گزارشtimeout چک لینک‌هانحوه برخورد با status codeهای لینک‌های بیرونیرا تغییر دهد.چک‌های مورد نیاز (Functional Requirements – Checks)HSC باید مجموعه‌ای از sanity checks زیر را فراهم کند:چک ✔ Missing Imagesآیا فایل تصویری که در img src آمده واقعاً وجود دارد؟چک ✔ Broken Internal Linksآیا href="#XYZ" واقعاً به یک id تعریف‌شده اشاره می‌کند؟چک ✔ Missing Local Resourcesمانند css، js، pdf و سایر منابعی که لینک شده‌اند اما وجود ندارند.چک ✔ Duplicate IDsآیا یک id دوبار تعریف شده؟چک ✔ Malformed Linksاشکالات syntax در href یا ساختار لینک‌ها.چک ✔ Illegal Link Targetsاهداف لینک ناسازگار یا نادرست.چک ✔ Broken External Linksبررسی status code لینک‌های HTTP.چک ✔ Broken ImageMapsبررسی ابتدایی صحت ImageMap.این چک‌ها بخش عمده‌ی دامنه عملکردی سیستم را تشکیل می‌دهند و بعداً در Building Block View تبدیل به ماژول‌ها و CheckerClassهای جداگانه خواهند شد.۱.۲ اهداف کیفی (Quality Goals)برای اینکه معماری HSC بتواند نیازهای واقعی کاربران را پوشش دهد، باید بدانیم این سیستم در بلندمدت به چه کیفیت‌هایی متعهد است. این اهداف کیفی، تصمیمات معماری را شکل می‌دهند و مشخص می‌کنند سیستم چه چیزی را باید همیشه تضمین کند.در HSC، کیفیت‌ها در سه محور اصلی خلاصه می‌شوند:۱) صحت (Correctness)مهم‌ترین هدف کیفیتی HSC، درست‌بودن نتایج است.سیستم باید:هر لینک داخلی شکسته را پیدا کند.هرگونه خطای معنایی احتمالی را گزارش دهد حتی در موارد مشکوک یا مبهم.به‌عبارتی، HSC باید «وسواسی» عمل کند؛ اگر در صحت لینک تردید دارد، باید گزارش دهد و تصمیم نهایی را به کاربر بسپارد.۲) ایمنی (Safety)یک اصل غیرقابل‌مذاکره:HSC هرگز نباید محتوای فایل‌های HTML را تغییر دهد.کارش فقط تحلیل است، نه بازنویسی، اصلاح یا اعمال تغییرات.۳) انعطاف‌پذیری (Flexibility)HSC باید بتواند:چندین الگوریتم بررسی مختلف را پشتیبانی کند،فرمت‌های متنوع گزارش تولید نماید،و در کلاینت‌های مختلف اجرا شود: Gradle، CLI و غیره.این انعطاف‌پذیری جزو اهداف کیفیتی سطح دوم است، اما برای معماری اهمیت عملی دارد.۴) تست‌پذیری و صحت درونی سیستمهر چکر (checker) باید هم برای موارد مثبت و هم موارد منفی تست شود.این موضوع کیفیت «درونی» سیستم را تضمین می‌کند و اجرای خودکار تست‌ها بخشی از معماری سیستم است.۵) کارایی (Performance)چک کردن یک فایل HTML حدود ۱۰۰ کیلوبایت باید زیر ۱۰ ثانیه انجام شود—البته بدون احتساب زمان راه‌اندازی Gradle.این هدف نشان می‌دهد کارایی مهم است، اما بعد از صحت و ایمنی قرار می‌گیرد.۱.۳ ذینفعان (Stakeholders)HSC یک سیستم کوچک است و ذینفعان محدودی دارد؛ اما همین تعداد کم نیز خواسته‌های متفاوتی دارند که در معماری اثر می‌گذارد.نویسندگان مستنداتکسانی که محتوا را با ابزارهای تولید HTML (مثل Asciidoctor) ایجاد می‌کنند.هدف‌شان این است که مطمئن شوند لینک‌ها، تصاویر و منابع HTML درست کار می‌کنند.کاربران arc42افرادی که می‌خواهند یک نمونهٔ ساده و واقعی از مستندسازی معماری مشاهده کنند.HSC برای این گروه نقش یک مثال آموزشی را دارد.توسعه‌دهندگان نرم‌افزارکسانی که می‌خواهند:کیفیت لینک‌ها و تصاویر داخل مستندات را بررسی کنند،HSC را در خط build خود ادغام کنند،و یک مثال عملی از معماری کوچک اما تمیز ببینند.این سه گروه، خواسته‌های معماری سیستم را تعریف می‌کنند.II.2 محدودیت‌ها (Constraints)در طراحی HSC، مجموعه‌ای از محدودیت‌ها وجود دارد که آزادی عمل معماری را تعیین می‌کنند و تصمیم‌ها را شکل می‌دهند.۱) باید روی پلتفرم‌های مختلف اجرا شودHSC باید مستقل از پلتفرم باشد و روی Windows، Linux و MacOS قابل اجرا باشد.۲) پیاده‌سازی مبتنی بر JVMزبان پیاده‌سازی باید Java یا Groovy باشد.این موضوع انتخاب runtime و سازگاری ابزار را مشخص می‌کند.۳) ادغام با Gradleسیستم باید به‌صورت پلاگین Gradle قابل استفاده باشد.این محدودیت تأثیر مستقیم بر ساختار پروژه و نحوهٔ بسته‌بندی ماژول‌ها دارد.۴) قابلیت اجرا از خط فرمانCLI باید مستقل از ابزار ساخت باشد؛ یعنی کاربر بتواند تنها با نصب ابزار، آن را اجرا کند.۵) حداقل وابستگی‌هاHSC باید سبک باشد. فقط به یک Java Runtime نیاز دارد و نباید کتابخانه‌های سنگین یا پیچیده داشته باشد.۶) لایسنس متن‌باز و سازگارکد باید تحت Apache-2.0 منتشر شود و دیگر کتابخانه‌های استفاده‌شده باید با Creative Commons سازگار باشند.این محدودیت‌ها مسیر طراحی را مشخص می‌کنند و در بخش‌های بعدی معماری منعکس خواهند شد.II.3 محدوده و کانتکست سیستم (System Scope & Context)۳.۱ کانتکست کسب‌وکاری (Business Context)برای فهم محدوده سیستم، باید بدانیم HSC با چه موجودیت‌هایی در محیط خود تعامل دارد.Business contextکاربر (User)کسی که مستندات می‌نویسد یا خروجی HTML تولید می‌کند.هدف او این است که مطمئن شود فایل HTML خروجی سالم، بدون لینک شکسته و بدون تصویر گم‌شده باشد.سیستم Build (اغلب Gradle)HSC معمولاً بخشی از pipeline تولید مستندات است.در این نقش:Gradle HSC را اجرا می‌کند،HSC HTMLها را بررسی،و گزارش تولید می‌کند.فایل‌های HTML محلیورودی اصلی سیستم هستند.HSC این فایل‌ها را parse و بررسی می‌کند.تصاویر و فایل‌های محلیسیستم باید بررسی کند که فایل‌هایی که HTML به آن‌ها لینک داده، واقعاً وجود داشته باشند.منابع خارجی (external web resources)کاربر می‌تواند بخواهد لینک‌های بیرونی نیز چک شوند.اما این بخش:کندتر است،ممکن است به دلیل مشکلات شبکه نتایج نادرست بدهد.بنابراین یک سناریوی اختیاری است که محدودیت‌های خاص خود را دارد.II.4 استراتژی راه‌حل (Solution Strategy)برای اینکه معماری HTML Sanity Check (HSC) بتواند اهداف کیفی تعریف‌شده—مثل صحت، ایمنی، انعطاف‌پذیری و کارایی—را پاسخ دهد، مجموعه‌ای از تصمیم‌ها و راهبردهای بنیادی در طراحی این سیستم اتخاذ شده است. این بخش خلاصه‌ای از ایده‌های کلیدی پشت معماری HSC را بیان می‌کند؛ ایده‌هایی که همهٔ افراد درگیر در توسعه، تست و نگهداری سیستم باید با آن‌ها آشنا باشند.۱) انتخاب Groovy و Java با کمترین وابستگی خارجیهستهٔ اصلی HSC عمدتاً با Groovy و بخشی از آن با Java پیاده‌سازی شده است.این انتخاب چند دلیل معماری مهم دارد:نیاز به حداقل وابستگی‌ها برای اجرای سریع و سبکامکان سازگاری کامل با JVM و ابزارهای مرتبطقابلیت نوشتن چکرها و منطق تحلیل HTML به‌صورت ساده، مختصر و خوانااین تصمیم مستقیماً کیفیت‌های ایمنی، قابلیت نگهداری و کارایی را تقویت می‌کند.۲) تبدیل سیستم به یک پلاگین Gradle برای اجرای خودکاربرای اینکه HSC بتواند بخشی طبیعی از فرآیند ساخت (build pipeline) باشد، پیاده‌سازی آن در قالب یک Gradle Plugin انجام شده است.نتیجهٔ این تصمیم:امکان استفادهٔ خودکار در CI/CDسازگاری با تیم‌هایی که اسنادشان را با Asciidoctor و Gradle تولید می‌کننداجرای کاملاً بدون دخالت انسانپلاگین Maven نیز در حال توسعه است تا این سناریو در محیط‌های گسترده‌تر هم برقرار شود.این استراتژی پاسخ مستقیمی به نیاز انعطاف‌پذیری و سهولت ادغام است.۳) استفاده از Template Method Pattern برای پشتیبانی از چندین الگوریتم بررسیبرای اینکه HSC بتواند:چکرهای مختلف داشته باشد،خروجی‌ها را در چند قالب تولید کند (مثل HTML و Console)،و قابلیت گسترش‌پذیری داشته باشد،در طراحی آن از الگوی Template Method استفاده شده است.این الگو باعث می‌شود:ساختار کلی الگوریتم ثابت بماند،اما بخش‌های قابل تغییر (مثل نوع چک یا نوع گزارش) قابل جایگزینی باشند،افزودن چکرهای جدید بدون دست‌زدن به ساختار کلی سیستم انجام شود.این انتخاب معماری، کیفیت‌های درست‌کارکردن، انعطاف‌پذیری و قابلیت توسعه را تضمین می‌کند.۴) اتکا به conventions استاندارد Gradle و Groovy برای تنظیماتHSC یک فایل پیکربندی ساده دارد که مطابق conventions این اکوسیستم است.این یعنی:کاربر بدون نیاز به تنظیمات پیچیده می‌تواند ابزار را اجرا کندرفتار سیستم به‌روشنی قابل انتظا‌رش استخروجی‌ها، ورودی‌ها و مسیرها استاندارد و قابل پیش‌بینی‌انداین تصمیم کیفیت استفاده‌پذیری و سادگی نگهداری را تقویت می‌کند.البته، همین وابستگی به conventions ممکن است برای نسخهٔ Maven Plugin چالش‌هایی ایجاد کند، زیرا ساختار Maven با Gradle متفاوت است.II.۵ نمای بلوک‌های سازنده یا Building Block Viewدر نمای سازه‌ای (Building Block View)، معماری سیستم از نگاه ایستا بررسی می‌شود:سیستم از چه بخش‌هایی ساخته شده است؟ این بخش‌ها چگونه سازمان‌دهی شده‌اند؟ و هر بخش چه مسئولیتی دارد؟در HSC، این ساختار به شکل عملکردهای تجزیه شده (Functional Decomposition) طراحی شده است: هستهٔ سیستم تمام منطق بررسی HTML را انجام می‌دهد، و بخش‌های دیگر فقط روش‌های مختلف استفاده از این هسته را فراهم می‌کنند.این بخش در سه سطح توضیح داده می‌شود:Level 1: ساختار کلی سیستم (Whitebox HtmlSC)Level 2: اجزای داخلی هستهٔ سیستم (HSC Core)Level 3: اجزای داخلی مدیریت نتایج (Results Collector)بیایید قدم‌به‌قدم جلو برویم.5.1 ساختار سطح ۱ – HtmlSanityChecker (Whitebox)در بالاترین سطح، HSC از چند بلوک اصلی تشکیل شده است.در این سطح هدف این است که «نقش‌های کلیدی سیستم» را مشخص کنیم، نه جزئیات پیاده‌سازی را.چرا این ساختار؟به‌جای اینکه همهٔ وظایف در یک پکیج یا کلاس قرار بگیرند، مسئولیت‌ها تفکیک شده‌اند:هستهٔ HSC → مسئول تحلیل HTML و اجرای چک‌هاپلاگین‌ها (مثل Gradle Plugin) → مسئول نحوه اجرا و ادغام HSC در ابزارهای خارجیابزارهای کمکی مثل NetUtil و FileUtil → برای بررسی شبکه و سیستم فایلرابط کاربری گرافیکی (UI) → پیش‌بینی شده، ولی هنوز پیاده‌سازی نشدهمهم‌ترین بخش‌ها در سطح کلان:۱) HSC Coreمرکز تمام منطق بررسی HTML؛ شامل پارس HTML، اجرای چک‌ها، تولید پیشنهاد و جمع‌آوری نتایج.۲) Gradle Pluginراهی برای استفاده از HSC در build pipeline پروژه‌ها.۳) NetUtilابزار کمکی برای بررسی اتصال اینترنت و وضعیت لینک‌های HTTP.۴) FileUtilابزار کمکی برای مدیریت فایل‌ها و مسیرها.۵) Graphical UI (برنامه‌ریزی شده)نسخهٔ گرافیکی احتمالی HSC برای کاربران غیرتکنیکال.5.2 ساختار سطح ۲ – HSC Core (Whitebox)در این سطح، وارد قلب سیستم می‌شویم؛ جایی که تمام منطق تحلیل HTML قرار دارد.هستهٔ HSC بر اساس «تفکیک وظیفه‌ای» ساخته شده است. یعنی بخش‌های مختلف هر کدام یک وظیفهٔ روشن دارند و باهم برای رسیدن به هدف کنار می‌آیند.الگوهای اصلی ساختار Core:مدیریت پیکربندیخواندن و پارس فایل‌های HTMLاجرای چک‌های مختلفتولید پیشنهاد (Suggestions)جمع‌آوری نتایج برای تولید گزارشبلوک‌های اصلی Level 2:۱) Checker (Blackbox)مهم‌ترین بخش سیستم.اینجا یک کلاس انتزاعی (abstract) وجود دارد به نام Checker.تمام چکرها از آن ارث‌بری می‌کنند.وظیفه آن:تعریف یک رابط یکسان (check())پیاده‌سازی الگوریتم چک با Template Method Patternاین ساختار اجازه می‌دهد:انواع چک‌ها (لینک شکسته، تصویر گم‌شده، ID تکراری و…) به‌سادگی افزوده شوندرفتار مشترک در superclass تعریف شودفقط بخش‌های متفاوت override شونداین بخش دقیقاً پاسخ‌دهندهٔ کیفیت انعطاف‌پذیری و قابلیت توسعه است.۲) AllChecksRunnerپردهٔ نمایشی (Facade) بین Core و دنیای بیرونی.این بخش:تمام چکرها را مدیریت می‌کندبراساس پیکربندی تعیین می‌کند چه چک‌هایی اجرا شوندخروجی همهٔ چک‌ها را جمع‌آوری می‌کندپلاگین Gradle مستقیماً این بخش را فراخوانی می‌کند.۳) Configurationهمه‌چیز در HSC قابل پیکربندی است:مسیر فایل‌هامسیر گزارش خروجیtimeout بررسی لینک‌هاوضعیت‌هایی که باید خطا یا هشدار محسوب شوندانواع چک‌هایی که باید فعال باشنداین بخش یکی از پایه‌های کیفیت انعطاف‌پذیری (Flexibility) است.۴) Reporterنتایج چک‌ها باید:یا در کنسول چاپ شوندیا به صورت فایل HTML یا متن ذخیره شوندReporter این مسئولیت را بر عهده دارد.این طراحی اجازه می‌دهد در آینده Report Formatهای جدید هم اضافه شوند.۵) Suggester (Blackbox)بخش جذاب سیستم!وقتی یک خطا پیدا می‌شود، HSC سعی می‌کند نزدیک‌ترین گزینهٔ صحیح را پیشنهاد دهد.مثلاً اگر نویسنده نوشته باشد: و تصویر واقعی logo.png باشد، Suggester باید بتواند این پیشنهاد را ارائه دهد.این بخش با الگوریتم Jaro-Winkler Distance کار می‌کند تا شباهت رشته‌ها را پیدا کند.کاربردهایش:تصویر گم‌شده → پیشنهاد تصویر مشابهلینک داخلی خراب → پیشنهاد id نزدیک5.3 ساختار سطح ۳ – Results Collector (Whitebox)این بخش مسئول سازمان‌دهی نتایج چک‌هاست و ساختاری کاملاً سلسله‌مراتبی دارد.سه سطح نتیجه وجود دارد:۱) PerRunResultsنتیجهٔ کلی برای یک اجرای کامل HSC(ممکن است شامل چندین فایل HTML باشد)۲) SinglePageResultsنتایج چک‌های یک فایل HTML مشخص۳) SingleCheckResultsخروجی یک چکر خاص؛ مانند:چک MissingImagesچک BrokenLinksچک DuplicateIDs۴) Findingهر خطا یا هشدار یک Finding است.می‌تواند شامل توضیح و حتی پیشنهاد از Suggester باشد.این ساختار چند مزیت دارد:گزارش‌ها تمیز و قابل فهم می‌شوندافزودن چک‌های جدید ساده استساختار گزارش‌دهی با نیازهای مختلف (CLI، HTML، IDE) هماهنگ می‌ماندII.۶ رفتار سیستم در زمان اجرا یا Runtime Viewمعماری ایستا به ما می‌گوید سیستم از چه بخش‌هایی تشکیل شده است؛اما Runtime View توضیح می‌دهد که این بخش‌ها هنگام اجرا چگونه با یکدیگر تعامل می‌کنند.در HSC دو سناریوی اصلی وجود دارد:II.۶.۱ سناریو اول: اجرای همهٔ چک‌هااین سناریو رایج‌ترین حالت استفاده از HSC است—زمانی که کاربر یا سیستم Build می‌خواهد مجموعه‌ای از فایل‌های HTML را بررسی کند.فرایند اجرای چک‌ها به صورت زیر پیش می‌رود:۱) اجرای هدف (Task) توسط کاربر یا سیستم Buildکاربر معمولاً دستور htmlSanityCheck را اجرا می‌کندیا Gradle در طی یک Build آن را فراخوانی می‌کند.۲) Gradle کنترل را به HSC منتقل می‌کندGradle تسک sanityCheckHtml را اجرا می‌کند که مستقیماً به HSC متصل است.۳) HSC پیکربندی را بارگذاری می‌کنداین شامل موارد زیر است:مسیر HTMLهای ورودیمسیر خروجی گزارشtimeout لینک‌هافعال یا غیرفعال بودن چک‌های مختلف۴) ایجاد AllChecksRunnerاین بخش «موتور اجرای چک‌ها»ست.AllChecksRunner مسئول است:چکرها را آماده کندفایل‌های ورودی را جمع کندو اجرای چک‌ها را مدیریت کند۵) جمع‌آوری فایل‌هاHSC تمام فایل‌هایی را که باید بررسی شوند در یک مجموعه (allFiles) جمع می‌کند.۶) (برنامه‌ریزی‌شده) کشف خودکار Checkerهادر نسخهٔ آینده، HSC قرار است به‌وسیلهٔ Annotationها چکرهای موجود را کشف کند تا توسعهٔ آن آسان‌تر شود.۷) اجرای چک‌ها و جمع‌کردن نتایجهر Checker روی HTML اجرا می‌شود و یافته‌ها (Findings) در ساختار سلسله‌مراتبی نتایج ذخیره می‌شود.II.6.2 سناریو دوم: تولید گزارش چک‌هابعد از اجرا، HSC باید نتایج را با ساختاری قابل درک و هماهنگ ارائه دهد.این ساختار مطابق با سلسله‌مراتب ResultsCollector است:۱) نتایج سطح اجرا (PerRunResults)شامل:تاریخ و زمان اجراتعداد فایل‌های بررسی‌شدهپیکربندی اعمال‌شدهخلاصهٔ کلی نتایج۲) نتایج سطح صفحه (SinglePageResults)برای هر فایل HTML یک بخش جداگانه ایجاد می‌شود.در این مرحله:عنوان صفحهتعداد خطاهانوع خطاهانمایش داده می‌شود.۳) نتایج سطح چک (SingleCheckResults)برای هر چک—مثل بررسی لینک‌های داخلی یا تصاویر—یک بخش مستقل ایجاد می‌شود که شامل:فهرست یافته‌هاپیشنهادهای احتمالی برای اصلاح خطااین روش گزارش‌دهی باعث می‌شود خروجی HSC بسیار تمیز، قابل جستجو و قابل تحلیل باشد—درست مانند گزارش تست‌های واحد.II.۷ معماری استقرار یا HSC Deployment Viewدر Deployment View، معماری سیستم از نگاه محیط اجرا و نحوه استقرار آن بررسی می‌شود.با اینکه HSC ابزاری کوچک است، اما در معماری استقرار آن سه بازیگر اصلی نقش دارند:۱) سیستم توسعهٔ HSC (Development Environment)اینجا جایی است که خود HSC توسعه و کامپایل می‌شود.پیش‌نیازهای محیط توسعه:JDKGroovyGradleکتابخانهٔ Jsoup برای تحلیل HTMLدر این محیط خروجی باینری نهایی تولید و برای انتشار آماده می‌شود.۲) مخزن عمومی (Artifact Repository)بعد از Build، نسخهٔ کامپایل‌شده HSC (به‌صورت Plugin) در یک مخزن عمومی نظیر:Maven CentralGradle Plugin Portalمنتشر می‌شود.کاربران HSC باینری‌ها را مستقیماً از این مخازن دریافت می‌کنند.۳) سیستم کاربر (User Machine)کاربر نهایی HSC را روی سیستم خودش اجرا می‌کند؛ معمولاً در یکی از این سناریوها:در خط فرمان (CLI)به‌عنوان پلاگین Gradle داخل build.gradleهمراه با تولید مستندات AsciiDocپیش‌نیازهای کاربر:Java Runtime (نسخه ۱.۶ یا بالاتر)فایل build.gradle که پلاگین HSC در آن پیکربندی شده باشددر این سیستم است که:فایل‌های HTML ساخته می‌شوندHTML Sanity Check اجرا می‌شودو گزارش نهایی تولید می‌شودII.8 مفاهیم فراگیر (Cross-cutting Concepts)در هر سیستم نرم‌افزاری مجموعه‌ای از قواعد، الگوها و مفاهیم وجود دارد که فقط مربوط به یک بخش خاص نیستند؛ بلکه در سراسر معماری دیده می‌شوند. در HSC این مفاهیم شامل الگوهای طراحی، مدل دامنه، ساختار لینک‌های HTML، الگوریتم‌های بررسی، و نحوهٔ گزارش‌دهی است.در ادامه، چهار مفهوم مهم HSC را به زبان ساده و معمارانه بررسی می‌کنیم.8.1 مدل دامنه (Domain Model)برای اینکه HSC بتواند HTML را تحلیل کند، ابتدا باید مفاهیم اصلی مرتبط با ساختار HTML را در قالب یک «مدل دامنه» تعریف کند. این مدل تعیین می‌کند که سیستم چه چیزهایی را می‌شناسد و با چه مفاهیمی کار می‌کند.در ادامه مهم‌ترین مفاهیم دامنه را توضیح می‌دهیم:مفهوم Anchorهمان تگ که لینک ایجاد می‌کند.Anchor همیشه شامل یک link target است.Cross Reference (لینک داخلی)لینکی که به بخشی دیگر از همان صفحه یا همان سند اشاره می‌کند.این همان چیزی است که HSC باید بررسی کند تا ببیند آیا id مقصد واقعاً وجود دارد یا نه.External Link (لینک بیرونی)لینکی که به یک صفحهٔ وب یا دامنهٔ دیگر اشاره می‌کند.بررسی این لینک‌ها حساس است، چون ممکن است مشکلات شبکه باعث خطاهای ظاهری شود.Finding در HSCهر مشکلی که یکی از Checkerها پیدا می‌کند—مثلاً «تصویر logo.png پیدا نشد».گاهی همراه با پیشنهاد برای رفع خطا است.HTML Element در HSCواحدهای سازندهٔ صفحه، مثل , ,
.برای تحلیل ساختاری HTML، HSC باید این عناصر را به‌درستی استخراج کند.HTML Page / Document در HSCیک فایل HTML کامل که شامل مجموعه‌ای از HTML elements است.حداقل شرط آن این است که parser بتواند آن را به‌درستی پردازش کند.id در HSCشناسهٔ یک عنصر در HTML، معمولاً هدف لینک‌های داخلی (href="#id").Internal Link / Local Link در HSCلینکی که به بخش دیگری از همین صفحه یا همین پروژه اشاره می‌کند.Link و Link Targetهر چیزی که از یک نقطه به نقطهٔ دیگر ارجاع می‌دهد.Link Target می‌تواند:یک id داخل همان صفحهیک فایل HTML دیگریا یک منبع خارجی باشدLocal Resource در HSCفایل‌هایی مثل PDF، CSS یا JS که صفحهٔ HTML به آن‌ها ارجاع می‌دهد.8.2 ساختار لینک‌های HTMLHSC بخش زیادی از کار خود را روی لینک‌ها انجام می‌دهد، بنابراین باید ساختار URI را عمیقاً بشناسد.یک URI معمولاً شامل این بخش‌هاست:پروتکل (http/https)آدرس میزبان (Host)شماره پورتمسیر فایلQuery stringFragment یا همان anchor (#someLabel)HSC با بررسی این ساختار می‌تواند تشخیص دهد:آیا لینک معتبر است؟آیا ساختار لینک درست نوشته شده؟آیا مقصد لینک وجود دارد؟این دانش در تمام Checkerها استفاده می‌شود.8.3 الگوریتم‌های بررسی (Checking Algorithms)یکی از تصمیم‌های طراحی مهم در HSC استفاده از Template Method Pattern برای تعریف الگوریتم‌های چک است.چرا این الگو انتخاب شد؟چون HSC چندین نوع چک مختلف دارد:چک لینک‌های داخلیچک فایل‌های تصویریچک تکراری بودن idهاچک لینک‌های بیرونیچک منابع محلیهمهٔ این چک‌ها ساختار کلی مشابهی دارند اما در جزئیات متفاوت هستند.Template Method این امکان را می‌دهد:اسکلت الگوریتم در یک کلاس پایه نوشته شودفقط بخش‌های متغیر در subclassها override شوندافزودن چک‌های جدید بسیار ساده باشدساختار کار این الگو در HSC:۱) چکر ساخته می‌شود۲) مقدمات اجرا (initResults) انجام می‌شود۳) متد performCheck() فراخوانی می‌شود۴) الگوریتم خاص چکر در متد check() اجرا می‌شود۵) نتایج جمع‌آوری و بازگردانده می‌شودبا این ساختار، توسعه‌دهندگان می‌توانند هر نوع چک جدیدی را بدون تغییر در هستهٔ سیستم اضافه کنند—این موضوع کیفیت انعطاف‌پذیری را تضمین می‌کند.8.4 سیستم گزارش‌دهی (Reporting)گزارش‌دهی نیز مانند چکرها از Template Method Pattern استفاده می‌کند.در HSC دو نوع خروجی گزارش وجود دارد:گزارش HTMLگزارش متنی (Console)اما در هر دو حالت، ساختار گزارش یکسان است:ایجاد بخش ابتدایی گزارش (initReport)نمایش خلاصهٔ کلی (صفحات بررسی‌شده، میزان موفقیت، تعداد خطاها)گزارش نتایج هر صفحهگزارش نتایج هر چک برای آن صفحهایجاد بخش انتهایی گزارش (footer)این ساختار یکپارچه باعث می‌شود:اضافه کردن فرمت‌های جدید گزارش بسیار ساده باشدساختار گزارش همیشه ثابت و قابل درک بماندبرنامه‌های دیگر بتوانند گزارش را به‌راحتی پردازش کننداین سیستم گزارش‌دهی، کیفیت قابلیت استفاده و قابلیت گسترش را افزایش می‌دهد.II.۹ تصمیمات معماری (Architecture Decisions)در این بخش، مهم‌ترین تصمیمات معماری که مسیر طراحی HSC را مشخص کردند توضیح داده می‌شود. این تصمیم‌ها معمولاً مواردی هستند که یا پرهزینه‌اند، یا ریسک دارند، یا نقش مهمی در کیفیت نهایی سیستم بازی می‌کنند. ثبت این تصمیمات به تیم توسعه کمک می‌کند منطق پشت انتخاب‌ها را درک کند.۹.۱ تعویق بررسی لینک‌های خارجیدر نسخه فعلی HSC، بررسی لینک‌های خارجی انجام نمی‌شود. این قابلیت عمداً به نسخه‌های آینده موکول شده است.چرا؟بررسی منابع بیرونی به شبکه وابسته استسرعت و پایداری آن قابل تضمین نیستممکن است نتایج نادرست بدهد (به‌دلیل timeout، مشکلات DNS، محدودیت سرور مقصد)بنابراین تیم توسعه تصمیم گرفته ابتدا روی قابلیت‌های داخلی و مطمئن تمرکز کند و سپس در نسخه‌های آینده سراغ لینک‌های خارجی برود.۹.۲ انتخاب Jsoup برای پارس HTMLHSC برای تحلیل ساختار HTML و استخراج لینک‌ها و تصاویر، نیاز به یک parser داشت. از میان گزینه‌های موجود، Jsoup انتخاب شد.دلایل این انتخاب:۱) بدون وابستگی خارجیJsoup یک کتابخانه سبک است و خودش به چیز دیگری وابسته نیست.این موضوع باعث می‌شود اندازه نهایی ابزار کوچک بماند و نصب آن آسان باشد.۲) API ساده و قدرتمندJsoup ترکیبی از:DOMCSS selectorsو سبک jQueryرا ارائه می‌دهد؛ یعنی با چند خط کد می‌توان:همهٔ لینک‌ها را پیدا کردهمهٔ تصاویر را استخراج کردهمهٔ idها را جمع کرد۳) انعطاف‌پذیری بالاJsoup می‌تواند ورودی را از فایل، رشته، stream یا منابع دیگر دریافت کند.جایگزین‌ها و دلیل رد شدنشانHTTPUnit → جهت تست وب‌سایت‌ها ساخته شده، وابستگی‌های زیاد داردHtmlCleaner → گزینه‌ای مناسب اما API محدودترJsoup در نهایت بهترین توازن را داشت: سبک، پرقدرت، سادهاین تصمیم قلب معماری سیستم را شکل می‌دهد، چون تمام چکرها به این ساختار DOM متکی هستند.II.10 نیازمندی‌های کیفی (Quality Requirements)کیفیت در HSC فقط یک مبحث تئوریک نیست؛ نیازمندی‌های کیفی این سیستم کاملاً قابل اندازه‌گیری و عملیاتی هستند. بخشی از این نیازها در ابتدای سند معرفی شدند و در این قسمت همان اهداف را به‌صورت دقیق‌تر و سناریومحور می‌بینیم.صحت (Correctness)HSC باید تضمین کند که:هر لینک داخلی شکسته شناسایی شودهر تصویر گم‌شده تشخیص داده شودتمام چکرها با تست مثبت و منفی اعتبارسنجی شونداین یعنی هیچ خطا یا هشدار نباید از چشم سیستم پنهان بماند.کامل بودن گزارش (Completeness)گزارش خروجی باید شامل تمام یافته‌ها باشد—حتی موارد جزئی.انعطاف‌پذیری (Flexibility)سیستم باید به‌گونه‌ای طراحی شود که:چکر جدید به آن اضافه شودگزارش‌دهی در قالب‌های جدید توسعه یابداز سیستم‌های build دیگر (غیر از Gradle) هم قابل استفاده باشدایمنی (Safety)HSC باید همیشه تمام فایل‌ها را بدون تغییر باقی بگذارد.این یک اصل غیرقابل‌مذاکره است:هیچ تغییری در HTML ورودی نباید ایجاد شود.کارایی (Performance)برای یک فایل HTML به اندازه ۱۰۰ کیلوبایت، تمام چک‌ها باید در کمتر از ۱۰ ثانیه انجام شوند.(بدون احتساب زمان startup Gradle)II.11 ریسک‌ها و بدهی فنی (Risks & Technical Debt)HSC پروژه کوچکی است، اما همچنان شامل چند ریسک فنی و تجاری است که باید به آن‌ها توجه شود.۱۱.۱ ریسک‌های فنی۱) وابستگی به یک توسعه‌دهندهدر حال حاضر فقط یک نفر دسترسی انتشار نسخه‌های جدید پلاگین را دارد.در صورت غیبت او، انتشار نسخه‌های جدید یا رفع اشکال ممکن است متوقف شود.۲) حساسیت نسبت به تغییرات Gradleبه‌روزرسانی Gradle در گذشته نیازمند تغییرات دستی در HSC بوده.هر ارتقای API ممکن است دوباره وقت‌گیر شود.این دو ریسک ممکن است در آینده هزینه‌زا باشند.۱۱.۲ ریسک‌های تجاری / دامنه‌ایاحتمال از رده خارج شدن سیستماگر AsciiDoc یا Markdown در آینده قابلیت بررسی لینک و تصویر را به‌صورت داخلی اضافه کنند:HSC ممکن است کارکرد اصلی خود را از دست بدهدنیاز به مدل کسب‌وکار جدید یا ارزش افزوده جدید خواهد بوداین ریسک استراتژیک است و به روند توسعه ابزارهای تولید مستندات بستگی دارد.II.12 واژه‌نامه (Glossary)برای اینکه ارتباط بین کاربران و توسعه‌دهندگان شفاف باشد، لازم است مفاهیم کلیدی دامنهٔ HSC معنی مشخصی داشته باشند.Linkهر ارجاعی در فایل HTML که کاربر را به بخشی دیگر یا منبع دیگری هدایت می‌کند.Cross Referenceنوعی لینک داخلی که به یک id داخل همان صفحه اشاره می‌کند.External Hyperlinkلینکی که خارج از دامنهٔ فعلی (مثلاً به یک وب‌سایت دیگر) اشاره می‌کند.Run Resultنتیجهٔ کامل یک اجرای HSC روی چندین فایل.SinglePageResultsخروجی تمام چکرها برای یک فایل HTML مشخص.بخش پایانیدر نهایت، مثال HTML Sanity Check نشان می‌دهد که حتی یک ابزار کوچک و مینیمال هم می‌تواند معماری شفاف، قابل‌توسعه و حرفه‌ای داشته باشد—به‌شرط آنکه از یک الگوی مستند‌سازی استاندارد مانند arc42 استفاده شود. این مثال ثابت می‌کند که معماری فقط مخصوص سیستم‌های عظیم و سازمانی نیست؛ حتی پروژه‌های کوچک نیز با داشتن یک ساختار معماری اصولی، درک‌پذیرتر، پایدارتر و قابل نگه‌داری‌تر می‌شوند.مستندسازی HSC نشان داد چگونه:تصمیمات کوچک مثل انتخاب Jsoupالگوهای طراحی مانند Template Methodو مفاهیم دامنه‌ای واضح مانند Link، Finding و HTML Elementمی‌توانند در کنار هم یک سیستم ساده را به یک نمونهٔ عالی از معماری تمیز و قابل توسعه تبدیل کنند.این مقاله همچنین گام‌به‌گام نشان داد که arc42 چگونه کمک می‌کند:بخش‌های کلیدی یک سیستم را شناسایی کنیمتعامل اجزا را درک کنیمکیفیت‌ها را قابل اندازه‌گیری کنیمو ریسک‌های احتمالی را از ابتدا شفاف کنیمبدون داشتن چنین چارچوبی، تحلیل و توسعهٔ سیستم—even اگر کوچک باشد—در بلندمدت هزینه‌بر و گیج‌کننده خواهد شد.با رشد ابزارهای خودکار، سیستم‌های توزیع‌شده، و توسعهٔ محصول مبتنی بر هوش مصنوعی، اهمیت داشتن مستند معماری استاندارد روزبه‌روز بیشتر می‌شود. arc42 یکی از روش‌هایی است که هم برای سیستم‌های بزرگ کاربردی است، هم برای ابزارهای کوچک مثل HSC؛ و همین موضوع، ارزش آن را در چرخهٔ عمر محصول دوچندان می‌کند.اگر نیاز دارید معماری پروژه‌های خود را استاندارد کنید، مستند arc42 بسازید، یا معماری فعلی‌تان را بازطراحی و عملیاتی کنید، تیم معماری و توسعه‌ی نرم‌افزار شرکت راهکار نگار هوشمند (آرکان) همراه شماست—از تحلیل اولیه تا مستندسازی و پیاده‌سازی کامل.این مقاله با هدف آگاهی‌بخشی توسط تیم توسعه‌ی نرم‌افزار شرکت راهکار نگار هوشمند (آرکان) تهیه شده است.#معماری_نرم‌افزار#arc42#مستندسازی_معماری#تحلیل_سامانه#طراحی_سیستم#معماری_فنی#HTMLSanityCheck#Software_Architecture#architecture_documentation#design_patterns#clean_architecture#devtools#quality_engineering#technical_writing#شرکت_راهکار_نگار_هوشمند#arcanco

وقتی که Mooji درباره‌ی خودِ واقعی حرف می‌زند: روایت من از یک گفت‌وگوی عمیق

محمد حسین جلیلی — Sat, 29 Nov 2025 13:07:25 +0330
در این مقاله، محتوای یک گفت‌وگوی مفصل و درونی با Mooji رو مرور می‌کنم؛ کسی که سال‌هاست درباره‌ی خودشناسی، رهایی از هویت‌های ذهنی، و تجربه‌ی آگاهی ناب صحبت می‌کنه.در این گفت‌وگو، او نه فقط درباره‌ی مفاهیم، بلکه از طریق پرسش‌هایی ساده، مخاطب رو دعوت می‌کنه تا تجربه‌ای مستقیم از سکوت درون و آگاهی بی‌واسطه داشته باشه.این نوشته، خلاصه‌ای‌ست از حرف‌های کلیدی او و تمرینی که در پایان گفت‌وگو اجرا می‌کنه؛ تمرینی که بدون پیچیدگی، مخاطب رو به نقطه‌ای می‌رسونه که در آن، چیزی باقی می‌مونه که نه فکره، نه خاطره، نه تصویر.اگر به گفت‌وگوهایی از این جنس علاقه‌مندی – گفت‌وگوهایی که بیشتر از اینکه اطلاعات بدهند، راهی برای دیدن باز می‌کنند – این روایت می‌تونه برات مفید باشه.https://youtu.be/RIjTlEBwrHQ?si=8FopudSwjbHQObkW«رنج ما از آنِ ما نیست»یکی از اولین چیزهایی که Mooji در این گفت‌وگو بهش اشاره کرد، چیزی بود که در نگاه اول شاید ساده بیاد، ولی وقتی دقیق‌تر نگاه کنی، می‌فهمی چقدر بنیادین و مهمه.اون گفت: ما به چیزهایی چسبیده‌ایم که ذاتاً ناپایدارند. و این چسبیدن‌ها منبع اصلی رنج ما هستند.چیزهایی مثل خاطراتمون، تعریف‌هامون از خودمون، حتی این فکر که «من کی‌ام؟» هم یه جور توهمه. ما به این فکر چسبیده‌ایم. و جالب اینه که همش در حال تغییره، ولی ما روش حساب باز می‌کنیم انگار قراره بمونه.موچی می‌گه: «حتی خود تصویری که از «خودت» داری، یه پدیده‌ست. یه چیزیه که میاد و می‌ره. یه فکره. ولی تو خودِ اون فکر نیستی. تو اون چیزی هستی که داره اون فکر رو می‌بینه.»این حرف خیلی توی ذهنم موند. چون معمولاً وقتی حالم بده، فکر می‌کنم باید حالم خوب بشه. ولی هیچ‌وقت از خودم نمی‌پرسم: کی داره به این حال نگاه می‌کنه؟موچی می‌گه: «چیزهایی که از حواس یا ذهن می‌گذره، همه میان و می‌رن. و چیزی که میاد و می‌ره، نمی‌تونه خودت باشه. چون اگه تو واقعاً اونا بودی، با رفتنشون تو هم باید می‌رفتی.»ولی ما هنوز این اشتباه رو می‌کنیم که فکر می‌کنیم ما همون فکرهامون هستیم. همون حس‌هامون. همون خاطره‌هامون.این جمله‌ش برای من خیلی مهم بود:«انسان‌ها به دنبال چیزی می‌گردند، بدون اینکه بدونن دقیقاً دنبال چی هستن. ولی اون چیز، در توست… چیزی که نمیاد و نمی‌ره. چیزی که همیشه اینجاست.»راستش نمی‌دونم چرا این جمله تا این حد آرومم کرد. شاید چون حس کردم دیگه لازم نیست دنبال چیزی بگردم بیرون از خودم…تمرینی برای دیدن آگاهیدر ادامه‌ی گفت‌وگو، Mooji یک تمرین ساده و مشخص انجام داد تا کمک کنه مخاطب درک روشنی از «آگاهی ناب» پیدا کنه.او از مهمان خواست برای چند دقیقه، همه‌چیز را کنار بگذارد:گذشته‌اش رافکر درباره‌ی آینده‌اش راحتی تعریف‌هایی که از خودش داردتمام افکار و خاطرات و دغدغه‌هاتأکید داشت که این فقط برای چند لحظه است، نه برای همیشه.بعد از این مرحله، از او خواست که ببیند چه چیزی باقی می‌ماند.سپس سوال‌هایی مطرح کرد، با هدف روشن شدن آن‌چه بعد از کنار گذاشتن همه‌چیز، همچنان «هست».مثلاً پرسید:آیا چیزی که باقی مانده، شکلی دارد؟رنگ دارد؟اسم دارد؟می‌تواند بیمار شود؟می‌شود آن را از دست داد؟آیا از بین می‌رود؟پاسخ مهمان در بیشتر موارد «نه» بود. و Mooji در پایان گفت:آن‌چه باقی مانده، همان حقیقت خودِ توست.آن چیزی که نه زاده شده، نه می‌میرد، نه محدود است، و نه قابل تملک.چیزی که همیشه بوده و همیشه هست.در واقع، با این تمرین می‌خواست نشان دهد که هویت واقعی انسان، چیزی فراتر از ذهن و تجربه‌های شخصی است. چیزی که در پسِ همه‌چیز وجود دارد و فقط باید آن را دید.وقتی خودت نیستی، رابطه‌ها واقعی‌تر می‌شندر بخش‌های بعدی گفت‌وگو، صحبت به سمت رابطه‌ها کشیده شد؛ مخصوصاً رابطه‌های عاشقانه یا نزدیک.Mooji در این قسمت توضیح می‌ده که وقتی انسان خودش رو فقط یک «شخص» می‌دونه – یعنی با ذهن و فکرهاش هم‌هویت می‌شه – رابطه‌ها پر از ترس، کنترل، وابستگی، و آسیب می‌شن.اما وقتی از اون تصویر ذهنی جدا می‌شه، شکل رابطه هم تغییر می‌کنه.اون گفت در بسیاری از روابط، ما در واقع دنبال تأیید گرفتن برای تصویری از خودمون هستیم، نه تجربه‌ی واقعی از بودن با طرف مقابل. و این باعث می‌شه رابطه به‌جای اینکه رشد ایجاد کنه، تبدیل به وسیله‌ای برای حفظ ترس‌ها بشه.به‌جای این، Mooji پیشنهاد می‌ده رابطه از جایی شکل بگیره که انسان به خودش نیاز نداره که «کامل» بشه؛ بلکه از کامل بودن خودش، با دیگری به اشتراک می‌ذاره، نه اینکه چیزی «بگیره».او گفت:رابطه‌ای که از آگاهی شکل بگیره، وابسته نیست، اما عمیقه. در اون رابطه، آزادی وجود داره، نه ترس از دست دادن.او حتی یک جمله‌ی جالب هم گفت:«در واقع، هر رابطه‌ای یک رابطه‌ی معنویه. چون همه‌ی رابطه‌ها آینه‌هایی هستن برای شناخت خود.»تأکید کرد که عشق واقعی، نیاز به تملک نداره.نیاز نیست طرف مقابل حتماً حضور فیزیکی یا احساسی دائمی داشته باشه.حتی گفت می‌شه کسی رو دوست داشت، بدون اینکه اون شخص حتی بدونه.این نوع از عشق، ریشه در آگاهی داره، نه در ترس یا کمبود.بیداری یعنی بازگشت، نه پیشرفتدر پایان گفت‌وگو، Mooji بارها به این نکته برگشت که «آگاهی» چیزی نیست که باید آن را به‌دست آورد یا خلق کرد. بلکه چیزی‌ست که همیشه هست؛ فقط باید حواسمان را از چیزهای دیگر برداریم تا دوباره آن را ببینیم.او گفت بسیاری از انسان‌ها فکر می‌کنند برای رسیدن به حقیقت یا بیداری معنوی، باید اطلاعات بیشتری یاد بگیرند، تکنیک‌های بیشتری تمرین کنند، یا از یک نقطه‌ی خاص به نقطه‌ای بالاتر برسند.اما مسیر واقعی، از جنس «شدن» نیست؛ از جنس «بازگشتن» است.بیداری یعنی از بین بردن آن‌چیزی که نیستی – نه اضافه کردن چیز جدید.Mooji تأکید کرد که رشد معنوی، یک نوع «بی‌شدن» است.آهسته آهسته لایه‌هایی از باورها، نقش‌ها، ترس‌ها و تصویرهای ساختگی از خود را کنار گذاشتن، تا چیزی که همیشه آنجا بوده، خودش را نشان دهد.او حتی گفت که گاهی ترس هم بخشی از این مسیر است.چون ذهن مقاومت می‌کند و نمی‌خواهد از تعاریف قبلی دست بردارد.اما پشت این ترس، آزادی واقعی قرار دارد.نه آزادی در انجام هر کاری، بلکه آزادی از نیاز به انجام کاری برای اثبات خود.در نهایت گفت:«تو چیزی هستی که نه می‌تونه فراموش بشه، نه از بین بره، نه بیمار بشه، نه گم بشه. فقط کافیه یاد بگیری ساکت باشی، و ببینی که اون همیشه بوده.»پایان مقالهاین مصاحبه، دعوتی بود برای دیدن چیزی که همین حالا هست.نه در آینده، نه با تمرین زیاد، نه در مفاهیم پیچیده.همه‌ی حرف Mooji این بود که:به جای جمع کردن، رها کن.به جای دانستن، ببین.به جای تعریف کردن خودت، با خودت ساکت باش.و در همین سادگی، چیزی هست که عمیق‌تر از تمام دانسته‌هاست.من دارم مجموعه‌ای از روایت‌ها می‌نویسم از ویدیوها، گفت‌وگوها و آدم‌هایی که حرف‌هاشون ارزش شنیدن و تأمل کردن داره.اگر دنبال اینی که ببینی از دل هر گفت‌وگوی خوب، چه نکته‌هایی می‌شه بیرون کشید، خوشحال می‌شم دنبالم کنی.#خودشناسی #آگاهی #رهایی_ذهن #سکوت_درون #معنویت #مقاله #روایت #گفتگوی_عمیق #رشد_فردی #توسعه_فردی #موچی#روایت_معنوی #ذهن_آگاه #زندگی_درونی #آگاهی_ناب #مراقبه #ویدیو_الهام_بخش #سفر_درونی #فلسفه_زندگی

راهنمای arc42؛ استاندارد جهانی برای مستندسازی معماری نرم‌افزار

محمد حسین جلیلی — Sat, 29 Nov 2025 11:49:29 +0330
اگر درگیر طراحی سیستم‌های مبتنی بر میکروسرویس‌ها، سیستم‌های توزیع‌شده، معماری کلان‌داده، سامانه‌های سازمانی یا توسعه‌ی نرم‌افزار مقیاس‌پذیر هستید، شناخت arc42 به شما کمک می‌کند معماری‌تان را نه‌تنها بهتر طراحی کنید، بلکه بتوانید آن را طوری مستند کنید که برای همه اعضای تیم قابل فهم و قابل توسعه باشد.در شکل زیر می‌توانید یک نمای کلی از arc42 داشته باشید:arc42 چیست؟arc42 یک قالب استاندارد برای مستندسازی معماری نرم‌افزار است.نه یک ابزار است، نه یک فریم‌ورک؛ فقط یک ساختار هوشمندانه که به تو کمک می‌کند به دو سؤال حیاتی پاسخ بدهی:چه چیزهایی باید درباره معماری سیستمم توضیح بدهم؟چطور باید آن‌ها را توضیح بدهم؟arc42 مثل یک کمد با کشوهای برچسب‌خورده عمل می‌کند:هر کشو موضوع مشخصی از معماری را در خود دارد.در نسخه کامل arc42 تعداد ۱۲ کشو وجود دارد که تقریبا همه چیز از «اهداف سیستم» تا «تصمیم‌های مهم معماری» و «کیفیت‌های سیستمی» را پوشش می‌دهد.به خاطر همین ساختار شفاف، arc42 کمک می‌کند معماری سیستم—حتی اگر پیچیده باشد—با کمترین هزینه قابل توضیح و قابل درک شود.چرا arc42 تا این حد محبوب است؟معمولاً دو دلیل باعث می‌شود تیم‌ها و سازمان‌ها عاشقش شوند:۱) مستندسازی قابل فهمساختار استاندارد arc42 باعث می‌شود هر کسی—چه توسعه‌دهنده تازه‌وارد، چه مدیر فنی—بتواند به‌سرعت معماری را بفهمد.این یعنی سردرگمی کمتر، زمان آموزش کمتر و تصمیم‌گیری سریع‌تر.۲) مستندسازی بدون دردبه آن می‌گویند “painless documentation”.چون مجبور نیستی زمان زیادی صرف نوشتن توضیحات پراکنده و بی‌ساختار کنی.فقط کافی است کشوها را پر کنی؛ همین.مزیت اصلی arc42: وضوح + کارآمدیarc42 از تو می‌خواهد معماری را در یک بستر قابل‌فهم و قابل تکرار توضیح بدهی.این یعنی هر بخش از معماری، تصمیم‌ها و وابستگی‌ها در یک جای مشخص و روشن قرار می‌گیرند.نتیجه؟معماری‌ای که:قابل خواندن استقابل نگهداری استقابل انتقال به تیم‌های جدید استو در جلسات مدیریتی اعتماد ایجاد می‌کندسؤال معروف: چرا اسمش «۴۲» است؟این بخش کمی فان است.سازندگان arc42 اسمش را از رمان معروف “Hitchhiker’s Guide to the Galaxy” گرفته‌اند؛ جایی که عدد ۴۲ به‌عنوان:«پاسخ نهایی به سؤال زندگی، جهان و همه‌چیز»معرفی می‌شود.arc42 هم برای معماری قصد دارد همان جواب نهایی باشد—حداقل از نگاه سازندگانش!📦 بخش‌های arc42 و توضیح هر کدام۱. Introduction and Goalsدر این بخش توضیح می‌دهید چرا این سیستم ساخته می‌شود و چه اهدافی دارد.شامل موارد زیر است:نیازمندی‌ها و اهداف سیستمذینفعان (stakeholders) و انتظارات آن‌هااهداف کیفی مهم (Quality Goals) که روی معماری تأثیر مستقیم دارنداین بخش باید تصویری کلی از سیستم بدهد و توضیح بگوید «هدف از این معماری چیست و برای چه مشکلی طراحی شده است».۲. Constraintsاین بخش شامل تمام محدودیت‌هایی است که طراحی معماری را شکل می‌دهند:محدودیت‌های فنی (مثلاً اجبار به استفاده از زبان یا سرویس خاص)محدودیت‌های سازمانی (خط‌مشی‌ها، استانداردها، رویه‌ها)محدودیت‌های محیطی و قانونیاین‌ها همان خطوط قرمز پروژه‌اند. معماری باید با این محدودیت‌ها سازگار باشد.۳. Context and Scopeدر این بخش محدوده سیستم و تعاملات آن با محیط بیرون مشخص می‌شود:سیستم شما دقیقاً کجای دنیا قرار می‌گیرد؟چه بازیگران یا سیستم‌هایی با آن تعامل دارند؟چه چیزهایی داخل محدوده سیستم هستند و چه چیزهایی خارج آن؟نتیجه این بخش معمولاً شامل یک دیاگرام کلی و توضیح روابط/اینترفیس‌ها است.۴. Solution Strategyدر اینجا تصمیم‌های بزرگ و بنیادین معماری ثبت می‌شود:سبک معماری انتخاب‌شدهرویکرد کلی برای تقسیم‌بندی سیستمانتخاب تکنولوژی‌های مهمروش‌های رسیدن به اهداف کیفیتاین بخش نگاه «کلان» به معماری را ارائه می‌کند.۵. Building Block Viewاینجا ساختار ایستای سیستم نمایش داده می‌شود:ماژول‌ها، لایه‌ها، بسته‌ها و کامپوننت‌هانحوه‌ی وابستگی آن‌هاتوضیح هر جزء با رویکرد Black-Box / White-Boxاین بخش مثل نقشه طبقات یک ساختمان است: چه چیزهایی کجا قرار دارند و چه کار می‌کنند.۶. Runtime Viewدر این بخش توضیح داده می‌شود که اجزای سیستم در زمان اجرا چگونه با هم تعامل می‌کنند:سناریوهای مهم اجرامسیر دادهتعامل کامپوننت‌هارفتار سیستم در شرایط خاص (استارتاپ، خطا، پردازش درخواست و …)این بخش رفتار واقعی سیستم را نشان می‌دهد، نه فقط ساختار کد را.۷. Deployment Viewدر این بخش زیرساخت و محیط اجرای سیستم نمایش داده می‌شود:سرورهامحیط‌های استقرار (dev, staging, production)شبکه، پیکربندی‌ها و توپولوژیاینکه هر جزء نرم‌افزار روی کدام ماشین/نود اجرا می‌شوداین دید برای تیم‌های DevOps و عملیات حیاتی است.۸. Crosscutting Conceptsمفاهیم و الگوهایی که چند بخش سیستم را تحت تأثیر قرار می‌دهند، اینجا مستند می‌شوند:احراز هویتلاگینگ و مانیتورینگاستانداردهای معماریقواعد طراحیالگوهای مشترک پیاده‌سازیاینجا قوانین مشترک سیستم را یکجا توضیح می‌دهید.۹. Architecture Decisionsاین بخش مخصوص ثبت تصمیم‌های مهم معماری است:موضوع تصمیمزمینه و دلیل آنگزینه‌های بررسی‌شدهتصمیم نهاییپیامدهای مثبت و منفیاین کار کمک می‌کند در آینده بدانید «چرا» یک انتخاب انجام شده.۱۰. Quality Requirements (Quality)الزامات کیفیتی سیستم در این بخش مشخص می‌شوند:کیفیت‌هایی مثل امنیت، کارایی، مقیاس‌پذیری، نگه‌داشت‌پذیریساختار درخت کیفیت (Quality Tree)سناریوهای دقیق کیفیت برای ارزیابی اهدافاین بخش کمک می‌کند معماری فقط از نظر عملکرد، نه بلکه از نظر کیفیت هم قابل سنجش باشد.۱۱. Risks and Technical Debtدر این بخش موارد زیر مستند می‌شود:ریسک‌های فنی و عملیاتیمشکلات شناخته‌شدهبدهی فنی موجودبخش‌هایی که احتمال مشکل‌دار شدن دارندهدف این است که نسخه‌ی شفاف و قابل پیگیری از ریسک‌ها وجود داشته باشد.۱۲. Glossaryاین قسمت شامل واژه‌ها و اصطلاحات مهم پروژه است:اصطلاحات دامنه کسب‌وکاراصطلاحات فنی اختصاصی پروژههدف: همه اعضای تیم یک معنی واحد از واژه‌ها داشته باشند.در پایان، باید گفت که قالب arc42 تنها یک الگوی مستندسازی نیست؛ بلکه رویکردی نظام‌مند برای شفاف‌سازی معماری، یکپارچه‌سازی دانش تیم، کاهش ریسک‌ها و تسهیل توسعه در بلندمدت است. چه در حال طراحی یک سامانه‌ی میکروسرویسی باشید، چه یک سیستم بلادرنگ، ERP سازمانی، پلتفرم گیمیفیکیشن یا اپلیکیشن مقیاس‌پذیر، arc42 کمک می‌کند از ابتدا معماری را درست تعریف کنید و با تیم‌تان به درک مشترک برسید.در آینده با رشد معماری‌های مدرن، سیستم‌های توزیع‌شده و توسعه‌ی محصول با کمک هوش مصنوعی، استفاده از الگوهای استانداردی مانند arc42 به یکی از نیازهای اصلی تیم‌های نرم‌افزاری تبدیل خواهد شد. این قالب نه‌تنها سرعت تصمیم‌گیری را بالا می‌برد، بلکه امکان نگهداری، توسعه و مقیاس‌پذیری سیستم را بسیار آسان‌تر می‌کند.اگر برای طراحی معماری، مستندسازی حرفه‌ای، یا پیاده‌سازی arc42 در پروژه‌های نرم‌افزاری خود نیاز به مشاوره دارید، تیم معماری و توسعه‌ی نرم‌افزار شرکت راهکار نگار هوشمند (آرکان) با تجربه‌ی عملی در پروژه‌های بزرگ، از همراهی با شما خوشحال خواهد شد.این مقاله با هدف آگاهی‌بخشی توسط تیم توسعه‌ی نرم‌افزار شرکت راهکار نگار هوشمند (آرکان) تهیه شده است.#معماری_نرم‌افزار#arc42#مستندسازی_معماری#سازه_نرم‌افزار#سیستم_توزیع_شده#میکروسرویس#طراحی_سیستم#software_architecture#architecture_documentation#enterprise_architecture#cloud_native#iot#devops#مهندسی_نرم‌افزار#technical_architecture#شرکت_راهکار_نگار_هوشمند#arcanco

مقیاس‌پذیری نرم‌افزار با مدل Virtual Actor در سیستم‌های توزیع‌شده

محمد حسین جلیلی — Fri, 28 Nov 2025 16:21:19 +0330
آیا تا به حال به این فکر کرده‌اید که چگونه می‌توان یک نرم‌افزار پیچیده و توزیع‌شده را به شکلی ساده، سریع و مقیاس‌پذیر طراحی کرد؟اگر با مفاهیمی مثل مدل بازیگر در نرم‌افزار، بازیگر مجازی (Virtual Actor) یا فریم‌ورک‌هایی مثل Proto.Actor آشنایی دارید یا می‌خواهید درک عمیق‌تری از آن‌ها پیدا کنید، این مقاله برای شما نوشته شده است.امروزه بسیاری از سازمان‌ها برای ساخت سامانه‌هایی با معماری پیشرفته، به سمت استفاده از مدل بازیگر (Actor Model) در سیستم‌های خود حرکت کرده‌اند. به‌ویژه در زمینه‌هایی مانند توسعه نرم‌افزار مقیاس‌پذیر، پردازش بلادرنگ و سیستم‌های توزیع‌شده، استفاده از مدل بازیگر یک رویکرد قدرتمند و عملیاتی است. در این مقاله، با تمرکز بر مفاهیم کلیدی، مثال‌های واقعی و معرفی ابزارهایی مانند Proto.Actor، به بررسی این مدل جذاب می‌پردازیم.در گذشته، بسیاری از برنامه‌ها بدون نیاز به مقیاس‌پذیری برای حجم‌های زیاد داده توسعه می‌یافتند. این وضعیت، فرآیند برنامه‌نویسی را نسبتاً ساده می‌کرد. کافی بود از یک مدل ساده‌ی شی‌گرا (Object-Oriented) استفاده کرده و داده‌ها را مستقیماً در حافظه پردازش کنید.اما امروز، مقیاس‌پذیری و پردازش حجم عظیمی از داده‌ها—به‌خصوص در راهکارهای اینترنت اشیاء (IoT)—به عناصر کلیدی در عملکرد برنامه‌ها و همچنین مزیت رقابتی استراتژیک آن‌ها تبدیل شده‌اند.مقیاس‌پذیری حالا خودش یک چالش واقعی است—و با خود، لایه‌ی کاملاً جدیدی از پیچیدگی را به همراه می‌آورد. در بسیاری از موارد، پشته‌ی فناوری (Tech Stack) مورد استفاده آن‌قدر پیچیده می‌شود که دیگر برای تیم‌های کوچک توسعه‌دهنده قابل مدیریت نیست.آیا می‌توان مقیاس‌پذیر شد بدون اینکه سادگی برنامه‌نویسی را فدا کرد؟با این حال، ممکن است راهی وجود داشته باشد تا بتوان در عین حفظ مدل برنامه‌نویسی ساده و رویدادمحور (event-driven)، برنامه را روی چند رشته (multi-threaded) و حتی چند ماشین (multi-machine) اجرا کرد.و همه‌ی این‌ها در همان محیط آشنا و دلخواه برنامه‌نویسی که به آن عادت دارید!اجازه دهید شما را با مفهومی آشنا کنم که این کار را ممکن می‌سازد:مدل بازیگرهای مجازی (Virtual Actors).مسأله چیست؟بیایید با یک نمایش ساده شروع کنیم. نگاهی بیندازید به یک اپلیکیشن نمونه که به‌عنوان دموی فریم‌ورک Proto.Actor ساخته شده است. این برنامه، حرکت اتوبوس‌ها در شهر تهران را به‌صورت بلادرنگ (real-time) ردیابی می‌کند.فرض کنیم می‌خواهیم اپلیکیشنی مشابه بسازیم، و این نیازها را داریم:موقعیت لحظه‌ای هر اتوبوس را نمایش دهد.مسیر طی‌شده‌ی اتوبوس در ۵ دقیقه گذشته را نشان دهد.نقشه را به‌صورت بلادرنگ (real-time) به‌روزرسانی کند، ولی فقط بخش‌هایی که برای کاربر قابل مشاهده هستند.موقعیت اتوبوس‌هایی که خارج از دید کاربر هستند، اصلاً از طریق شبکه منتقل نشود.تا اینجا چیز پیچیده‌ای نداریم. اما بیایید کمی چالش‌برانگیزترش کنیم و نیازهای زمانی و مکانی بیشتری اضافه کنیم:اگر یک اتوبوس بیش از ۱۰ دقیقه در جایی متوقف شده باشد و درب‌های آن بسته باشد، برای کاربر نوتیفیکیشن ارسال شود.سازمان صاحب اتوبوس‌ها می‌تواند محدوده‌های جغرافیایی (Geofence) تعریف کند. هر زمان که یک اتوبوس وارد یا خارج از این محدوده شد، به کاربر اطلاع داده شود.شاید بگویید که تهران با بیش از ۴۰۰۰ وسیله‌ی نقلیه‌ی عمومی فعال به‌صورت هم‌زمان، خیلی مقیاس بزرگی نیست. پس بیایید سناریو را بزرگ‌تر کنیم:برنامه باید قابلیت مقیاس‌پذیری برای تمام شهرهای بزرگ ایران را داشته باشد.حالا سؤال اینجاست:چگونه می‌توان اپلیکیشنی با چنین نیازهایی طراحی کرد؟رویکرد سنتیبرای حل این مسئله، روش‌های متعددی وجود دارد. یکی از آن‌ها به‌صورت زیر است:در این رویکرد سنتی، با مشکلات متعددی مواجه هستیم:در این مدل، هیچ تطابقی با دنیای واقعی وجود ندارد. نه مفهومی به نام "اتوبوس" داریم، نه "سازمان‌ها". در عوض، فقط با "جریان موقعیت‌ها (stream of positions)" سروکار داریم که باید پردازش شود.برای پردازش داده‌ها، باید روی پایگاه‌داده‌ی موقعیت‌ها، کوئری‌های سنگین و هزینه‌بر اجرا کنیم—و البته باید آن‌ها را کش (cache) کنیم تا عملکرد بهتری داشته باشیم.باید به مقیاس‌پذیری پایگاه‌داده نیز فکر کنیم: چگونه آن را توزیع کنیم؟ چگونه بار ترافیک را تقسیم کنیم؟باید تاخیر شبکه و پیچیدگی‌های ارتباطات توزیع‌شده را در طراحی در نظر بگیریم.با مشکلات همروندی (concurrency) دست‌و‌پنجه نرم می‌کنیم. اگر دو عملیات همزمان روی یک موقعیت اعمال شود چه؟ چه کسی مسئول هماهنگی است؟باید از یک پشته‌ی فناوری (tech stack) مقاوم و پیچیده استفاده کنیم—که البته این هم به توسعه‌دهندگانی با مهارت‌های گسترده و متنوع نیاز دارد.در کل، این معماری به‌مراتب پیچیده‌تر از چیزی است که برای این مسئله‌ی نسبتاً ساده لازم است. پیچیدگی موجود، ناشی از نیاز به مقیاس‌پذیری است.آیا راه ساده‌تری وجود دارد؟قطعاً خیلی خوب می‌شد اگر می‌توانستیم همه‌ی مفاهیم دنیای واقعی را به‌عنوان اشیاء (objects) در یک اپلیکیشن واحد مدل کنیم، و تمام الگوریتم‌ها را مستقیماً در حافظه اجرا کنیم.در این مدل، ما هر اتوبوس، سازمان، و محدوده‌ی قابل‌مشاهده روی نقشه (viewport) را به‌عنوان یک شیء منحصربه‌فرد در نظر می‌گیریم و تعامل بین آن‌ها را نیز به‌شکل شی‌گرا مدل‌سازی می‌کنیم.هر شیء دارای وضعیت داخلی (state) است، و می‌تواند آن را در واکنش به سیگنال‌هایی از دنیای بیرون یا سایر اشیاء، تغییر دهد.نتیجه چیست؟این برنامه بسیار آسان‌تر برای ساخت است نسبت به معماری سنتی قبلی، و به‌مراتب قابل‌فهم‌تر برای توسعه‌دهندگان.اما آیا چنین اپلیکیشن شی‌گرایی واقعاً مقیاس‌پذیر است؟ایرادی که می‌توان وارد کرد این است که:یک برنامه‌ی شی‌گرا و ساده، احتمالاً طبق نیاز ما قابل مقیاس‌پذیری نیست.ما نمی‌توانیم همه‌ی این اشیاء را روی یک ماشین واحد جای دهیم.و از طرفی راهی برای گسترش آن به چند ماشین هم وجود ندارد—حداقل نه در معماری شی‌گرای سنتی.یه جور دیگه بزار بگم:"ای کاش می‌شد همه چیز رو مثل دنیای واقعی، به‌صورت شی‌ء (object) در نظر بگیریم. هر اتوبوس، هر سازمان، هر محدوده‌ی نقشه → یک object مجزا، با وضعیت خاص خودش."و بعد، تمام منطق برنامه (مثل بررسی توقف ۱۰ دقیقه‌ای، عبور از geofence و...) رو داخل حافظه اجرا کنیم.نتیجه‌اش چی می‌شه؟برنامه ساده‌تر نوشته می‌شهراحت‌تر فهمیده می‌شهکمتر نیاز به هماهنگی بین اجزاء پیچیده داره🛑 اما مشکل کجاست؟مشکل اینه که:این مدل ساده فقط روی یک ماشین جواب می‌ده و اگر بخوای ده‌ها هزار شیء (اتوبوس و...) رو همزمان مدیریت کنی، حافظه و پردازنده‌ی یک سیستم جواب نمی‌ده.از طرف دیگه، معماری شی‌گرا به‌صورت سنتی، برای توزیع روی چند ماشین طراحی نشده.پاسخ: بله، راهی وجود دارد—"بازیگرهای مجازی" (Virtual Actors)مدلی به نام بازیگران مجازی (Virtual Actors)—که گاهی با نام "غله‌ها" (Grains) نیز شناخته می‌شوند—این امکان را فراهم می‌کنند که:مدل شی‌گرای ساده‌ی شما همچنان حفظ شوددر عین حال بتوان آن را به خوشه‌های بزرگی از ماشین‌ها گسترش دادبه‌طوری که هر ماشین، بخشی از اشیاء یا بازیگران را مدیریت کنداین یعنی می‌توانیم سادگی مدل برنامه‌نویسی شی‌گرا را با مقیاس‌پذیری افقی واقعی ترکیب کنیم—بدون پیچیدگی‌های معماری مرسوم!یعنی اینجوری بگم که:این مدل به ما اجازه می‌ده که:همون سبک ساده‌ی شی‌گرا رو حفظ کنیماما اشیاء (اتوبوس‌ها، سازمان‌ها، و...) در پشت صحنه روی چندین سرور پخش (توزیع) بشنهر سرور، فقط بخشی از اشیاء رو نگه‌داری و مدیریت می‌کنهو ما به‌عنوان توسعه‌دهنده، نیازی نداریم بدونیم شیء موردنظر کجاست یا کی بارگذاری می‌شه—همه چیز اتوماتیکهمدل بازیگر (Actor Model)بیایید ابتدا در مورد بازیگرهای معمولی و مدل اصلی Actor که در سال ۱۹۷۳ معرفی شد صحبت کنیم.این مدل به‌عنوان یک «مدل ریاضی برای محاسبات همروند (concurrent computation)» تعریف شده است،اما اجازه بده ساده‌تر توضیحش دهیم.🎭 بازیگر چیست؟یک Actor را مثل یک شیء تصور کن که:پیام‌ها را از یک صف (Queue) دریافت می‌کندیک وضعیت داخلی (In-Memory State) در حافظه نگه می‌داردمثلاً:بازیگر اتوبوس (BusActor) می‌تواند تاریخچه‌ی موقعیت‌های اخیر یک اتوبوس را در خودش ذخیره کند.بازیگر Geofence می‌تواند لیستی از اتوبوس‌هایی که در محدوده‌ی خاصی قرار دارند را نگه دارد.هر پیام جدیدی که دریافت می‌شود ممکن است این وضعیت را تغییر دهد (mutate).و چون همه چیز در حافظه اتفاق می‌افتد، این کار بسیار سریع‌تر از تعامل با دیتابیس انجام می‌شود.بعضی بازیگرها حتی می‌توانند روی دنیای بیرون اثر بگذارند (مثلاً چیزی در کنسول چاپ کنند، نوتیف بفرستند، یا به سیستم خارجی پاسخ دهند).وضعیت اجرا چگونه است؟پیام‌ها یکی‌یکی پردازش می‌شوند، آن هم روی یک Thread.وضعیت داخلی Actor فقط برای خودش است و از بیرون غیرقابل دسترسی.بنابراین:هیچ مشکل همروندی (Concurrency) نداریم.کدها ساده‌تر، قابل تست‌تر و بدون نیاز به قفل‌گذاری هستند.آیا این مدل واقعاً مقیاس‌پذیر است؟با وجود اینکه هر Actor فقط روی یک Thread اجرا می‌شود،پاسخ بله است.با ایجاد تعداد زیادی Actor و اجرای همزمان آن‌ها، می‌توانید به موازی‌سازی (Massive Parallelism) برسید.مثلاً:برای هر اتوبوس در شهر تهران، یک بازیگر جداگانه داشته باشید.این بازیگرها می‌توانند با هم کار کنند، بدون اینکه به وضعیت همدیگر دست بزنند.این چیزهایی که گفتیم خیلی انتزاعی بود، بگذارید یک نگاهی به کد داشته باشیم:public class HelloActor : IActor { public Task ReceiveAsync(IContext context) { if (context.Message is Hello helloMsg) Console.WriteLine($"Hello {helloMsg.Who}"); return Task.CompletedTask; } }توضیح کدpublic class HelloActor : IActorتعریف یک Actor با نام HelloActorاین کلاس از اینترفیس IActor پیروی می‌کند که نشان می‌دهد این کلاس می‌تواند پیام دریافت و پردازش کند.public Task ReceiveAsync(IContext context)متدی که در زمان دریافت پیام، توسط سیستم فریم‌ورک Proto.Actor فراخوانی می‌شود.آرگومان context اطلاعات مربوط به پیام و وضعیت فعلی بازیگر را در خود دارد.if (context.Message is Hello helloMsg)بررسی می‌کند که آیا پیام دریافتی از نوع Hello است یا نه.اگر بود، آن را به متغیر helloMsg تبدیل می‌کند که به داده‌های داخلش دسترسی داریم.Console.WriteLine($"Hello {helloMsg.Who}");خروجی چاپ می‌کند به صورت:Hello <نام ارسال‌کننده>مثلاً اگر Who = "Ali" باشد، خروجی می‌شود:Hello Alireturn Task.CompletedTask;نشان می‌دهد که بازیگر بعد از دریافت و پردازش این پیام، کاری ندارد.این متد باید Task برگرداند، و CompletedTask یعنی عملیات تموم شده.کاربرد در واقعیت چیه؟این کد می‌تونه بخشی از یک سیستم بزرگ باشه که در آن، بازیگرها به عنوان موجودیت‌هایی مستقل، هر کدام فقط مسئول یک نوع خاص از رفتار هستند—در اینجا مثلاً بازیگر سلام‌دهنده.حالا کد بعدی رو هم نگاه کنیم:public class BusActor : IActor { List _positionHistory = new(); public Task ReceiveAsync(IContext context) { switch (context.Message) { case Position position: _positionHistory = _positionHistory .Where(p => DateTimeOffset.UtcNow - p.Timestamp < TimeSpan.FromMinutes(5)) .ToList(); _positionHistory.Add(position); break; case GetPositionsHistoryRequest: context.Respond(new PositionBatch { Positions = _positionHistory }); break; } return Task.CompletedTask; } }توضیح BusActorpublic class BusActor : IActorتعریف یک کلاس Actor به نام BusActorاز رابط IActor پیروی می‌کند، یعنی یک Actor استاندارد در Proto.Actor استList _positionHistory = new();تعریف یک لیست از نوع Position برای نگه‌داری تاریخچه‌ی موقعیت‌های اتوبوساین لیست فقط آخرین ۵ دقیقه‌ی موقعیت‌ها را ذخیره می‌کندمثل حافظه‌ی داخلی یک GPS که فقط حرکات اخیر را نگه می‌داردpublic Task ReceiveAsync(IContext context)متدی که در زمان دریافت پیام، اجرا می‌شودcontext.Message حاوی پیام دریافتی استبا استفاده از switch نوع پیام بررسی می‌شودحالت اول: دریافت موقعیت جدیدcase Position position:اگر پیام دریافتی از نوع Position بود:_positionHistory = _positionHistory .Where(p => DateTimeOffset.UtcNow - p.Timestamp < TimeSpan.FromMinutes(5)) .ToList();این خط، فیلتر می‌کند که فقط موقعیت‌هایی که در ۵ دقیقه‌ی گذشته ثبت شده‌اند باقی بمانندموقعیت‌های قدیمی‌تر از لیست حذف می‌شوند._positionHistory.Add(position);موقعیت جدید دریافتی به لیست اضافه می‌شودحالت دوم: درخواست برای دریافت تاریخچه موقعیت‌هاcase GetPositionsHistoryRequest: context.Respond(new PositionBatch { Positions = _positionHistory }); break;اگر پیام دریافتی از نوع GetPositionsHistoryRequest بود:Actor به درخواست پاسخ می‌دهدپاسخ شامل شیئی از نوع PositionBatch است که شامل کل تاریخچه موقعیت‌هاستreturn Task.CompletedTask;این متد async است و باید یک Task برگرداندچون عملیات ما ساده و کوتاه است، یک CompletedTask کفایت می‌کندجمع‌بندی کارکرد کلی BusActor به صورت متنیوقتی یک پیام موقعیت جدید (Position) دریافت می‌شود، بازیگر لیست موقعیت‌های قبلی را بررسی می‌کند و فقط موقعیت‌هایی که در ۵ دقیقه‌ی گذشته ثبت شده‌اند را نگه می‌دارد. سپس، موقعیت جدید را به این لیست اضافه می‌کند.وقتی یک پیام درخواست تاریخچه (GetPositionsHistoryRequest) دریافت می‌شود، بازیگر به آن پاسخ می‌دهد و لیست موقعیت‌های فعلی را به‌صورت یک شیء جدید از نوع PositionBatch ارسال می‌کند.تمام ذخیره‌سازی داده‌ها فقط در حافظه انجام می‌شود. هیچ دیتابیسی در کار نیست، بنابراین خواندن و نوشتن اطلاعات بسیار سریع انجام می‌شود.پردازش پیام‌ها به‌صورت تک‌ریسمانی (single-threaded) انجام می‌شود، به همین دلیل هیچ مشکلی از نوع رقابت هم‌زمانی (concurrency) وجود ندارد. این یعنی نیازی به قفل‌گذاری یا مدیریت حالت پیچیده نیست.هر نمونه از BusActor فقط نماینده‌ی یک اتوبوس خاص است و کاملاً ایزوله عمل می‌کند. بازیگرها به‌طور مستقل رفتار می‌کنند و وضعیت‌شان را فقط خودشان تغییر می‌دهند.این بازیگرها می‌توانند در سیستم‌های توزیع‌شده روی نودهای مختلف یک خوشه (cluster) توزیع شوند، بدون اینکه تغییری در کد نیاز باشد.این ساختار به راحتی امکان مدیریت هزاران یا حتی میلیون‌ها بازیگر (مثل اتوبوس‌های مختلف) را فراهم می‌کند، درحالی‌که معماری ساده، قابل فهم و توسعه‌پذیر باقی می‌ماند.ماندگاری (Persistence)در بسیاری از موارد، اینکه فقط وضعیت بازیگر (Actor) در حافظه نگه‌داری شود، قابل‌قبول نیست.ما نیاز داریم که وضعیت بازیگر در برابر اتفاقاتی مثل ری‌استارت شدن ماشین، ارتقاء نرم‌افزار یا خاموشی‌ها، حفظ شود.اما از طرفی، قبلاً گفتیم که پردازش Actor خیلی سریع است چون کاملاً در حافظه انجام می‌شود.آیا این دو گزاره با هم تناقض دارند؟پاسخ: خیر، تضادی نیست. راه‌حل، ذخیره‌سازی هوشمند است.در عمل، بسیار رایج است که وضعیت بازیگرها در نوعی ذخیره‌ساز پایدار (persistent storage) نگهداری شود.ترجیحاً باید از دیتابیس‌هایی با عملکرد بالا استفاده شود، مثل:RedisAzure Table StorageGoogle Bigtableاما نکته‌ی مهم اینجاست:باید به وضعیت ذخیره‌شده، به‌چشم یک "تصویر لحظه‌ای (snapshot)" یا "بک‌آپ" نگاه کرد، نه به‌عنوان داده‌ی عملیاتی اصلی.نحوه‌ی استفاده:وضعیت بازیگر فقط زمانی بارگذاری می‌شود که بازیگر برای اولین‌بار در حافظه ایجاد می‌شود.نیازی نیست قبل از پردازش هر پیام، دوباره داده را از دیتابیس بخوانیم (برخلاف برنامه‌های stateless معمول).همین ویژگی به‌تنهایی می‌تواند تا ۵۰٪ از زمان صرف‌شده برای عملیات I/O را حذف کند.ضمناً:وضعیت موجود در حافظه، مرجع اصلی (source of truth) است، نه فقط یک cache موقت.بنابراین مشکلی به نام "همگام‌سازی کش (cache invalidation)" نخواهیم داشت.نوشتن وضعیت (Write Strategy):شما در ذخیره‌سازی وضعیت، انعطاف زیادی دارید. می‌تونید تصمیم بگیرید که:بعد از هر پیام، یک نسخه‌ی پشتیبان از وضعیت گرفته شود.یا پس از دریافت تعداد مشخصی پیامیا مثلاً هر چند دقیقه یک‌بار (بک‌آپ دوره‌ای)انتخاب این روش بستگی به نیازهای برنامه‌ی شما دارد.ارتباط (Communication)ارتباط در مدل Actor بسیار ساده اما قدرتمند است.شما می‌توانید از:کلاینتیا یک Actor دیگربه یک بازیگر پیام بفرستید، صرفاً با قرار دادن پیام در صف پیام‌های آن (message queue).این ارتباط به‌صورت ذاتی ناهمزمان (asynchronous) است.اما بعضی فریم‌ورک‌ها این ارتباط را با استفاده از APIهایی بر پایه‌ی:Task در .NETیا Promise در JavaScript و سایر زبان‌هاساده‌تر می‌کنند، به‌طوری‌که می‌توانید منتظر پاسخ بمانید، بدون اینکه ساختار برنامه‌تان پیچیده شود.در کد، ارتباط با بازیگر چطور انجام می‌شود؟شما معمولاً یک ارجاع (handle) به بازیگر موردنظر دارید و از طریق آن پیام می‌فرستید.مثلاً: ارسال پیام به بازیگر یک سازمان خاص.context.Send(OrganizationActorePid, position);در ادامه مقاله، یاد می‌گیریم که چطور حتی نیاز به نگه داشتن این ارجاع را هم حذف کنیم—که بخشی از قدرت مدل بازیگرهای مجازی است.سلسله‌مراتب بازیگرها (Actor Hierarchies)اگه مدل بازیگر (Actor Model) رو در گوگل یا هر موتور جستجو جستجو کنی،خیلی زود با نمودارهای پیچیده‌ای از سلسله‌مراتب بازیگرها مواجه می‌شی.مثلاً مثل این تصویر:چرا این نمودارها پیچیده هستند؟در مدل سنتی Actor:بازیگرها می‌تونند بازیگرهای فرزند (child actors) ایجاد کنند.مسئولیت چرخه‌ی عمر (lifecycle) بازیگرهای فرزند به عهده‌ی والد است.در صورت بروز خطا در زنجیره، Actor پدر مسئول رسیدگی به خطاهاست.اغلب استراتژی‌های خاصی برای مدیریت خطا (مثل بازنشانی، نادیده گرفتن یا جایگزینی) اعمال می‌شود.اما:ارتباط بین این سلسله‌مراتب‌ها، اگر روی ماشین‌های مختلف اجرا شوند، ساده و مستقیم نیست.خبر خوبدر بسیاری از برنامه‌های واقعی و مدرن،نیازی به این سطح از پیچیدگی وجود ندارد.مدل ساده‌تری هم هست که همان مزایا را دارد، ولی پیچیدگی‌ها را حذف می‌کند.ادامه مقاله: مدل بازیگرهای مجازی (Virtual Actor Model)در بخش بعدی مقاله، وارد دنیای بازیگرهای مجازی می‌شویم—جایی که:نیازی به مدیریت ارجاع مستقیم به Actorها نیستمدیریت حافظه، ماندگاری، مقیاس‌پذیری و ساختار Actorها به‌طور کامل خودکار و ساده‌سازی شده استبازیگرهای مجازی (Virtual Actors)بازیگرهای مجازی یا همان Grains این‌طور فرض می‌شوند که همیشه وجود دارند.شما هیچ‌گاه لازم نیست آن‌ها را به‌طور دستی ایجاد (create) یا حذف (destroy) کنید.این بازیگرها ممکن است در لحظه:در حافظه فعال باشند،یا غیرفعال شده باشند (مثلاً برای صرفه‌جویی در منابع).اما از دید کلاینتی که می‌خواهد با آن ارتباط برقرار کند، این تفاوت هیچ اهمیتی ندارد.تنها کاری که انجام می‌دهید، این است که یک پیام برای آن Actor می‌فرستید،و فریم‌ورک بازیگر مجازی به‌صورت خودکار اطمینان حاصل می‌کند که آن Actor فعال شده و آماده دریافت پیام است.شناسایی Actor چگونه انجام می‌شود؟در این مدل:نیازی به نگه‌داشتن اشاره‌گر (handle) یا ریفرنس مستقیم به Actor ندارید.به‌جای آن، مقصد پیام را بر اساس "نوع (type)" و "شناسه (id)" مشخص می‌کنید.یعنی می‌گویید:"می‌خوام با Actor نوع OrganizationActor با شناسه 42 صحبت کنم"نه اینکه یک متغیر به‌خصوص از اون Actor رو از قبل داشته باشید.خوشه‌بندی (Clustering)ویژگی‌هایی که در بالا توضیح دادیم باعث می‌شن مدل Actor مجازی به‌صورت شفاف (transparent) در سراسر چندین ماشین مقیاس‌پذیر باشد.یعنی:مکان Actor مهم نیست.تا زمانی که نوع و شناسه‌ی آن را بدانید، می‌توانید پیام بفرستید.فریم‌ورک به‌صورت خودکار پیام را به مکان درست مسیریابی (route) می‌کند.حتی اگر Actor به دلیل مثلا خاموش شدن نود، به مکان جدیدی منتقل شود (migrate)،کلاینت همچنان می‌تواند با آن بدون هیچ مشکلی ارتباط برقرار کند.نتیجه این رویکرد چیست؟این مدل، در عین اینکه ساده و قابل درک است،انعطاف‌پذیری و قدرت بالایی در مقیاس‌پذیری و توزیع‌شدگی در اختیار شما می‌گذارد—بدون اینکه مدل برنامه‌نویسی پیچیده شود.ابزارها و فریم‌ورک‌هادر دنیای .NET، چند فریم‌ورک محبوب برای پیاده‌سازی مدل Actor مجازی وجود دارند:OrleansProto.ActorAkka.NETهمچنین بخش‌هایی از Daprموارد استفاده (Use Cases)به‌طور کلی، زمانی که برنامه‌ی شما با تعداد زیادی موجودیت کوچک (small entities) سروکار دارد که:هرکدام منطق خودش را اجرا می‌کندو وضعیت خودش را به‌صورت ایزوله مدیریت می‌کندمدل Actor می‌تواند انتخاب بسیار مناسبی باشد.برای مثال‌های مشخص‌تر، اینجا چند مورد از کاربردهای متداول آورده شده است:مدل‌سازی یک دستگاه به‌عنوان Actor با منطق آلارم، قوانین و آستانه‌هادوقلوهای دیجیتال (Digital Twins) برای اشیاء فیزیکیمدیریت تعاملات کاربران به‌صورت پیام بین Actorهاجمع‌آوری و تحلیل جریان‌های داده به‌صورت نقشه‌کاهش (MapReduce)پیگیری وضعیت بازی‌ها، بازیکنان، اشیاء، منابع و امتیازهاسیستم‌های Matchmaking (مانند بازی‌های آنلاین)توزیع وظایف میان نودهای پردازشی مختلفوظایفی که به اجرای مستقل نیاز دارند و باید با هم تبادل اطلاعات داشته باشندنتیجه‌گیریمدل بازیگرهای مجازی (Virtual Actor Model)یک رویکرد قدرتمند و اثبات‌شده برای ساخت برنامه‌های توزیع‌شده است.با این مدل می‌توانید برنامه‌هایی بسازید که:کارایی بالا داشته باشنددر مقیاس بزرگ توزیع‌شده اجرا شوندو با همان ابزارهایی که هم‌اکنون با آن‌ها آشنایی دارید، توسعه پیدا کننددر پایان، باید گفت که مدل بازیگر، به‌ویژه در قالب بازیگرهای مجازی، فرصتی منحصربه‌فرد برای طراحی و توسعه‌ی معماری نرم‌افزار پیشرفته در اختیار تیم‌های نرم‌افزاری قرار می‌دهد. چه در حال ساخت یک سامانه‌ی مبتنی بر سیستم‌های توزیع‌شده باشید، چه در مسیر پیاده‌سازی توسعه نرم‌افزار مقیاس‌پذیر یا سرویس‌های بلادرنگ، این رویکرد می‌تواند به‌سادگی پیچیدگی‌ها را کاهش دهد.در آینده، به‌ویژه با رشد ابزارهایی مانند Proto.Actor در دنیای دات‌نت، استفاده از مفاهیمی مانند مدل بازیگر در نرم‌افزار به یکی از استانداردهای طراحی سیستم‌های بزرگ تبدیل خواهد شد. اگر به دنبال یادگیری عمیق‌تر، مشاوره یا اجرای پروژه‌هایی در این حوزه هستید، خوشحال می‌شویم در شرکت راهکار نگار هوشمند (آرکان) همراه شما باشیم.این مقاله با هدف آگاهی‌بخشی توسط تیم توسعه‌ی نرم‌افزار شرکت راهکار نگار هوشمند (آرکان) تهیه شده است.#سیستم_توزیع_شده#بازیگر_مجازی#توسعه_نرم_افزار#مشاوره_نرم_افزار#معماری_میکروسرویس#برنامه_نویسی#دات_نت#proto_actor#Orleans#cloud_native#IoT#real_time#نرم_افزار_سفارشی#شرکت_راهکار_نگار_هوشمند#arcanco

مهندسی نرم افزار در گوگل

محمد حسین جلیلی — Thu, 11 Apr 2024 16:09:45 +0330
این بلاگ خلاصه‌ای از تجربیات آقای Fergus Henderson هست که بیش از ده سال در گوگل، مهندس نرم افزار است و نشان می‌دهد که چگونه گوگل بازی توسعه نرم افزار را انجام می‌دهد.گوگل محصولات پیچیده و زیادی دارد مانند Google Search, AdWords, Maps و Android ... اما چگونه این همه محصولات را مدیریت می‌کنند و توسعه می‌دهد؟ما در این بلاگ سعی می‌کنیم که شیوه‌های مهندسی نرم‌افزار را که در گوگل استفاده می‌شود، بررسی کنیم و ببینیم که گوگل چگونه محصولات نرم افزاری خود را مدیریت می‌کند. دانستن فرآیند‌های یک شرکت موفق مانند گوگل می‌تواند یک معیار ارزیابی خوب برای سازمان‌های دیگر باشد.یکی از دلایل مهم موفقیت گوگل استفاده از این شیوه‌ها هست، مانند:· مخزن کد یکپارچه: گوگل تمام کدهای خود را در یک کتابخانه دیجیتالی عظیم نگه می دارد که هر مهندس می تواند به آن دسترسی داشته باشد. این مانند داشتن یک پوشه آنلاین غول پیکر و مشترک برای همه پروژه های Google است که پیدا کردن کد مورد نیاز و کار با آن را برای همه آسان تر می کند.· سیستم Build معروف به Blaze : آنها از ابزار خاصی به نام Blaze برای انجام کارهای سنگین کامپایل و تست کد استفاده می کنند. Blaze به‌عنوان یک خط مونتاژ تصور کنید که همه نرم‌افزارهایی را که Google می‌سازد کنار هم قرار می‌دهد و بررسی می‌کند و از اجرای روان همه چیز اطمینان می‌دهد.· بازنگری کد: قبل از اینکه هر کدی بخشی از پروژه های گوگل شود، مهدنس‌های دیگری آن‌ها را به طور کامل بررسی می کنند. این مرحله مطمئن می شود که کد نقص کمی دارد و کار تیمی را ارتقا می دهد.· تست کردن مداوم: گوگل به جای اینکه منتظر تست همه چیز باشد، دوست دارد نرم افزار خود را اغلب و در قطعات کوچک تست کند. این شبیه به چشیدن سوپ در حین پختن است و در آخر به جای همه چیز، چاشنی را کم کم تنظیم کنید.· مدیریت پروژه ها و افراد: گوگل روش هوشمندانه ای برای اجرای پروژه ها و مراقبت از مهندسان خود دارد. به عنوان مثال، مهندسان می توانند 20 درصد از زمان خود را صرف هر پروژه ای کنند که به آن علاقه دارند. این آزادی جرقه خلاقیت و ایده های جدید می دهد.· نرم‌افزار بازنویسی: گوگل به‌جای اینکه به قدیمی‌ها بچسبد، بیشتر نرم‌افزارهای خود را با نیاز‌های جدید و تکنولوژی‌های جدید بازنویسی می‌کند.1 توسعه نرم افزار1-1 مخزن کدبیشتر کد‌های گوگل در یک مخزن قرار دارند و اکثر مهندس‌ها به این مخزن دسترسی دارند.(( داده‌های کاربران کاملا محافظت شده هست، فقط کد‌ها برای مهندس‌ها در دسترس هست)). البته قسمت‌هایی از کد‌ها برای برخی از پروژه‌ها محافظت شده هستند. اما پروژه‌های متن باز مثلا اندروید و کروم کاملا قابل دسترس هستند. . دسترسی نوشتن برای اطمینان از کیفیت کد‌ها کنترل می‌شود، اما فرهنگ به گونه‌ای هست که هر مهندس را تشویق می‌کند تا در پروژه‌های مختلف مشارکت کنند و احساس مسئولیت جمعی برای دارایی‌های نرم‌افزاری شرکت را تقویت کند.توسعه همیشه روی head یا آخرین ورژن هست نه بر روی برنچ‌ها. این کار مشکلات merg و integrity را کاهش می‌دهد.سیستم‌های تست خودکار بر روی توسعه‌ها مرتبا در حال اجرا هست.موضوعات مالکیت کد‌ها هست از این جهت که کاملا مشخص است چه کدی را چه کسی زده است و آن شخص می تواند روی آن قسمت دسترسی‌هایی ایجاد کند و یا تغییری بدهد. این موضوع را در مخزن‌های مدیرت subtreeها می‌گویند و این باعث می‌شود که آن شخصی که تغییری را ایجاد می‌کند همان شخصی هست که بیشترین عمق شناخت از کد را دارد.1-2 سیستم Build در گوگلگوگل از یک سیستم ‌build توزیع شده به نام Blaze استفاده می کند تا فرآیند توسعه نرم افزار خود را ساده کند. Blaze عملیات کامپایل، Link، و تست نرم افزار را انجام می دهد و دستورات استانداردی را برای این وظایف در کل مخزن کد Google ارائه می دهد. بهینه‌سازی و یکنواختی آن، مراحل ساخت و تست را برای مهندسان ساده و تسریع می‌کند، و آنها را قادر می‌سازد تا به طور مؤثر روی پروژه‌هایی که فراتر از حوزه کاری خود هستند، کار کنند و در آنها مشارکت کنند. این سیستم یک محیط توسعه مشارکتی و انعطاف پذیر را فراهم کرده است.در فرآیند توسعه گوگل، برنامه نویسان فایل های “BUILD” را ایجاد می کنند که پیکربندی‌های Blaze است و این سیستم با استفاده از این فایل عملیات Build را انجام می‌دهد. این فایل ها حاوی دستورالعمل های سطح بالا یا "مشخصات ساخت" برای اجزای مختلف نرم افزار مانند کتابخانه ها، برنامه ها و تست ها هستند.در فرآیندBuild گوگل، هر مرحله Build به گونه‌ای طراحی می‌شود که «hermetic» باشد، به این معنی که صرفاً فقط از ورودی های صراحتاً اعلام شده خود استفاده می کند. این تضمین می کند که سیستم ‌Build به طور دقیق همه وابستگی‌ها را دارد، زیرا تنها ورودی های اعلام شده به ماشینی که Build را انجام می دهد ارائه می شود. این رویکرد به کامپایلرهای مورد استفاده در فرآیند Build، که به عنوان ورودی نیز در نظر گرفته می شوند، گسترش می یابد. این اصل hermetic، قابلیت اطمینان سیستم ‌Build را در مدیریت موثر وابستگی ها تضمین می کند.سیستم Build گوگل تضمین می کند که هر مرحله Build قطعی است، به این معنی که به طور مداوم خروجی یکسانی را با همان ورودی تولید می کند. این اجازه می دهد تا نتایج Build در کش ذخیره شود، و مهندسان نرم افزار را قادر می سازد تا به نسخه قبلی کار خود بازگردند و دقیقا همان باینری را بازتولید کنند. ماهیت قطعی فرآیند Build همچنین به این معنی است که این نتایج ذخیره شده در کش می توانند به طور ایمن بین کاربران مختلف به اشتراک گذاشته شوند و کارایی و همکاری را افزایش دهند. دستیابی به این امر مستلزم حذف هر چیز رندومی در ابزارهای Build، مانند حذف time stamp از فایل های خروجی برای اطمینان از نتایج ثابت است.سیستم ‌Build گوگل برای قابلیت اطمینان بالا طراحی شده است و نه تنها تغییرات کد، بلکه تغییرات در قوانین Build را ردیابی می کند. اگر تغییری در نحوه Build چیزی ایجاد شود، مانند تغییر در گزینه های کامپایلر بدون تغییر فایل های ورودی، سیستم به طور خودکار می داند که قسمت های آسیب دیده را بازسازی کند. علاوه بر این، وقفه‌ها را به خوبی مدیریت می کند. اگر یک Build در میانه راه متوقف شد یا اگر فایل ها در طول Build تغییر کردند، به سادگی راه اندازی مجدد دستور Build کافی است. هیچ نیازی به فرآیندهای پاکسازی دستی مانند «make clean» و streamlining development نیست.سیستم Build گوگل نتایج Build را کش می‌کند و علاوه بر آن نتایج میانی را هم ذخیره می‌کند و در نهایت در فضای ابری ذخیره می‌کند. این راه‌اندازی به آن اجازه می‌دهد تا به طور مؤثر از این نتایج برای درخواست‌های Build بعدی که به نتایج یکسانی نیاز دارند، استفاده مجدد کند و از Rebuild غیرضروری اجتناب کند. این ویژگی به طور کلی اعمال می‌شود، حتی زمانی که درخواست‌هایی از سوی کاربران مختلف ارائه می‌شود، کارایی را افزایش می‌دهد و زمان Build را در سراسر ‍‍‍‍‍‍پروژه کاهش می‌دهد.عملیات Rebuild تدریجی سریع است. سیستم Build در حافظه باقی می ماند به طوری که برای Rebuild می تواند به صورت تدریجی فقط فایل‌هایی را که از آخرین Build تغییر کرده اند تجزیه و تحلیل کند.1-3 باز نگری کد در گوگلگوگل ابزارهای مبتنی بر وب پیشرفته‌ای را برای بررسی کد، توسعه داده است که با ایمیل یکپارچه شده اند و روند بررسی را ساده می کند. این ابزارها با رنگبندی‌هایی که روی متن‌ها ایجاد می‌کنند راحتی کار را برای کسی که بازنگری می‌کند و کسی برنامه نویسی می‌کند فراهم کرده‌اند. وقتی بازنگری (code review) درخواست می‌شود، بازنگر از طریق ایمیل مطلع می‌شوند که یک لینک به تغییر خاص است که در ابزار مشخص است. آنها همچنین پس از ارسال نظرات بررسی، ایمیل را دریافت می کنند. علاوه بر این، سیستم‌های خودکار با ارسال اعلان‌هایی درباره نتایج تست یا یافته‌های ابزارهای تحلیل استاتیک، این فرآیند را بهبود می‌بخشند و یک گردش کار بررسی جامع و کارآمد را ارائه می‌دهند.فرآیند‌های Google موظف می‌کند که هر تغییری که در مخزن کد اصلی ایجاد می‌شود، توسط حداقل یک مهندس دیگر برای تضمین کیفیت بررسی شود. علاوه بر این، اگر شخصی که تغییر را انجام می‌دهد مالک فایل‌های در حال تغییر نیست، حداقل یکی از صاحبان فایل باید اصلاحات را بررسی و تأیید کند و اطمینان حاصل کند که تغییرات توسط کسانی که بیشتر با محتوا آشنا هستند نظارت می‌شوند.در شرایط اضطراری، صاحب کد می‌تواند تغییراتی را در بخش مخزن خود بدون بررسی قبلی انجام دهد. با این حال، باید یک بازنگر به آن تغییر اختصاص داده شود و تا زمانی که تغییر، بررسی و تایید نشود، هم فرد تغییر دهنده و هم بازنگر، یادآوری دریافت خواهند کرد. اگر بازنگر مشکلاتی را شناسایی کرد، هر گونه اصلاحات لازم باید از طریق ارسال جدید انجام شود، زیرا تغییر اولیه قبلاً در پایگاه کد ادغام شده است.گوگل از ابزارهای خودکار برای توصیه به بازنگران احتمالی برای تغییرات کد استفاده می‌کند، بر اساس عواملی مانند مالکیت کد، نویسنده، سابقه افرادی که تغییرات مشابه را بررسی کرده‌اند، و حجم کار بررسی فعلی هر نامزد. در حالی که حداقل یکی از مالکان ناحیه کد تحت تأثیر این تغییر باید آن را تأیید کند، نویسنده این امکان را دارد که بازنگر‌های دیگری را بر اساس اولویت خود انتخاب کند.چالشی که در فرآیند بررسی کد وجود دارد، احتمال تأخیر در صورت کندی بازنگران در تأیید تغییرات است که می تواند توسعه را کند کند. با این حال، گوگل با فراهم کرده اجازه‌هایی برای برنامه نویس، این مشکل را کاهش می دهد. این انعطاف‌پذیری به مهندسان اجازه می‌دهد تا بازنگر‌هایی را انتخاب کنند که بسته به پیچیدگی تغییر، سریع‌تر و مناسب‌تر پاسخ دهند، در نتیجه سرعت توسعه را با دوری از بازنگر‌های بیش از حد محتاط یا صاحب نظر برای به‌روزرسانی‌های ساده، حفظ کرده و بازنگر‌های با تجربه‌تر را برای تغییرات پیچیده انتخاب کنند.گوگل به طور خودکار بحث‌های بازنگری کد پروژه‌ها را به لیست ایمیل خاصی که توسط نگهدارند‌های پروژه مدیریت می شود ارسال می کند. این راه‌اندازی به هر کسی اجازه می‌دهد تا در هر زمانی قبل یا بعد از ایجاد تغییر، بدون توجه به نقش رسمی خود به‌عنوان بازنگر، درباره هر تغییر پیشنهادی نظر دهد. اگر یک اشکال بعداً شناسایی شود، این یک روش معمول است که تغییری را که باعث آن شده است پیدا کنند و در موضوع بررسی اصلی اظهار نظر کنند. این تضمین می کند که هم شخصی که تغییر را ایجاد کرده و هم بازنگران در مورد موضوع برای ارجاع و یادگیری در آینده مطلع می شوند.گوگل اجازه می‌دهد تغییرات کد توسط چندین نفر بررسی شود و به محض اینکه یک بازنگر، که باید مالک یا نویسنده باشد، آن را تأیید کند، اجازه می‌دهد تغییر انجام شود. این فرآیند می‌تواند حتی قبل از اینکه دیگر بازبینان بازخورد خود را ارائه دهند، رخ دهد. هر گونه نظر اضافی از بازبینان را می توان در به روز رسانی های بعدی بررسی کرد. این رویکرد به سرعت بخشیدن به روند بررسی با اجازه دادن به تأییدها و تنظیمات سریعتر بر اساس بازخورد کمک می کند.مخزن Google شامل یک بخش "تجربه" است که در آن قوانین سختگیرانه بررسی کد اعمال نمی شود. با وجود این، برای استفاده از کد در production، باید در بخش اصلی مخزن قرار گیرد. مهندسان به شدت تشویق می شوند که از همان ابتدا در بخش اصلی کار کنند و تأکید می کنند که بررسی کد در طول توسعه به جای بعد از آن سودمندتر است. با این وجود، معمولاً مهندسان به دنبال بررسی برای کار در بخش آزمایشی هستند و به بهترین شیوه ها برای تضمین کیفیت پایبند هستند.گوگل مهندسان خود را تشویق می‌کند تا تغییرات کوچک و قابل مدیریتی در کد ایجاد کنند، و پیشنهاد می‌کند که به‌روزرسانی‌های بزرگ‌تر باید به قطعات کوچک‌تر و قابل بررسی‌تر تقسیم شوند. این رویکرد نه تنها فرآیند بررسی را تسهیل می‌کند، بلکه به نویسندگان اجازه می‌دهد تا بازخورد را با سهولت بیشتری اجرا کنند. برای ترویج این عمل، ابزارهای بررسی کد گوگل تغییرات را بر اساس اندازه طبقه‌بندی می‌کنند، با برچسب‌هایی از «medium-size» برای تغییراتی که بر 30 تا 99 خط تأثیر می‌گذارند تا توصیف‌کننده‌هایی مانند «large» یا «freakin huge» برای تغییرات اساسی‌تر. این سیستم، در حالی که کاربردی است، اما با گیمیفیکیشن‌های خاصی به فرآیند‌ها تزریق می‌شود.1-4 تستگوگل تاکید زیادی بر تست واحد دارد و انتظار دارد تمام کدهای production با تست های واحد همراه باشد. ابزارهای بازبینی کد به طور خودکار هر فایل منبع جدیدی را که فاقدunit test است علامت گذاری می کند. بررسی‌کنندگان معمولاً اصرار دارند که هرگونه افزودن ویژگی‌های جدید با تست‌های جدید تطبیق داده شود تا اطمینان حاصل شود که عملکرد همانطور که در نظر گرفته شده است کار می‌کند. برای راحت کردن تست، حتی برای کدهایی که به کتابخانه های پیچیده وابسته هستند، مهندسان گوگل اغلب از mocking frameworks استفاده می کنند که امکان ایجاد تست های کارآمد و سبک را فراهم می کند.تست یکپارچه سازی و تست رگرسیون نیز به طور گسترده انجام می شود.گوگل همچنین ابزارهای خودکاری برای اندازه گیری test coverage دارد. نتایج همچنین به عنوان یک لایه اختیاری در مرورگر کد یکپارچه شده است.گوگل قبل از استقرار نرم‌افزار، تست load را الزامی می‌کند و تیم‌ها را ملزم می‌کند تا نحوه عملکرد سیستم در شرایط فشار مستند کنند. این شامل تولید داده‌هایی مانند جداول یا نمودارها است که شاخص‌های عملکرد کلیدی مانند تاخیر و نرخ خطا را در پاسخ به سطوح مختلف درخواست‌های کاربر نشان می‌دهند. این عمل تضمین می کند که سیستم ها در شرایط دنیای واقعی قوی و قابل اعتماد هستند.1-5 ردیابی bugگوگل از یک ابزار ردیابی bugبه نام Buganizer برای مدیریت مسائل مختلف از جمله bug، درخواست‌های featureو مشکلات مشتری، در کنار ردیابی انتشار و عملیات پاکسازی استفاده می‌کند. مشکلات موجود در Buganizerبه دسته‌هایی با قابلیت تخصیص کنترل‌کننده‌های پیش‌فرض و اطلاع دادن به اشخاص مربوطه از طریق ایمیل، سازمان‌دهی شده‌اند. مهندسان تشویق می شوند تا هرگونه تغییر کد ارائه شده برای بررسی را به versionهای خاص مرتبط کنند و ردیابی و حل مشکل سازمان یافته و کارآمد را تسهیل کنند و کاملا بفهمند که چه bugای در چه نسخه‌ای بوده و در چه وضعیتی هست.1-6 زبان‌های برنامه نویسیمهندسان نرم افزار در گوگل به شدت تشویق می شوند که به یکی از پنج زبان برنامه نویسی رسمی تایید شده در گوگل برنامه نویسی کنند: C++، Java، Python، Go یا JavaScript. به حداقل رساندن تعداد زبان های برنامه نویسی مختلف استفاده شده، موانع استفاده مجدد از کد و همکاری برنامه نویس را کاهش می دهد.گوگل برای اطمینان از سازگاری در code style، طرح‌بندی، و قراردادهای نام‌گذاری، راهنماهایی را برای زبان‌های برنامه‌نویسی مختلف حفظ می‌کند. علاوه بر این، گوگل یک برنامه آموزشی خوانایی کد را اجرا کرده است که در آن مهندسان با تجربه دیگران را در نوشتن کد واضح راهنمایی می کنند. این شامل بررسی تغییرات قابل توجه کد است تا زمانی که مربی از توانایی مربی در نوشتن کد قابل خواندن مطمئن شود. هر کد جدید قابل توجهی باید تاییدیه شخصی دریافت کند که استانداردهای خوانایی زبان را تایید کرده است و اهمیت کد واضح و قابل نگهداری را تقویت می کند.گوگل ارتباط بین زبان های برنامه نویسی مختلف را عمدتاً از طریق Protocol Buffers تسهیل می کند، روشی برای رمزگذاری موثر داده های ساختاریافته. بافرهای پروتکل شامل یک زبان تخصصی برای تعریف ساختارهای داده و یک کامپایلر است که کدی را برای مدیریت این ساختارهای داده در C++، جاوا و پایتون تولید می کند. این سیستم، که با کتابخانه‌های (RPC) Google یکپارچه شده است، به RPC‌های چندزبانه ساده اجازه می‌دهد تا به‌طور خودکار سریال‌سازی و سریال‌زدایی داده‌ها را در محیط‌های برنامه‌نویسی مختلف مدیریت کنند.گوگل فرآیند توسعه نرم افزار خود را با استفاده از مجموعه ای یکپارچه از دستورات برای وظایف مهندسی رایج در پایگاه کد گسترده و زبان های برنامه نویسی مختلف ساده می کند. این استانداردسازی به این معنی است که توسعه‌دهندگان می‌توانند بدون توجه به پروژه یا زبانی که با آن کار می‌کنند check out, edit, build, test, review, commit و گزارش باگ را با استفاده از دستورات مشابه انجام دهند. در نتیجه، توسعه دهندگان می توانند به راحتی بین پروژه ها بدون نیاز به یادگیری فرآیندهای جدید جابجا شوند و کارایی و سادگی در کار توسعه را افزایش دهند.1-7 رفع اشکال و ابزار‌های profilingگوگل اشکال زدایی سرور را با کتابخانه های مجهز به ابزارهایی که ثبت و تجزیه و تحلیل خطا را خودکار می کند، افزایش می دهد. در صورت خرابی سرور، این ابزارها به‌طور خودکار گزارش‌های خطا، از جمله stack tracesو core files را ضبط و ثبت می‌کنند. آنها همچنین می توانند مسائلی مانند سرریز حافظه را با logging the memory allocation at fault در خطا شناسایی کنند. به‌علاوه، Google رابط‌های وب را برای اشکال‌زدایی عمیق ارائه می‌کند، اطلاعاتی در مورد ارتباطات سرور، معیارهای عملکرد، و استفاده از منابع سیستم ارائه می‌دهد. این قابلیت‌ها امکان تنظیمات دقیق و عیب‌یابی را فراهم می‌کنند، و اغلب نیاز به روش‌های عیب‌یابی سنتی مانند استفاده از gdb را از بین می‌برند، بنابراین فرآیند اشکال‌زدایی را به طور قابل توجهی ساده می‌کنند.1-8 مهندسی انتشار یا Release engineerinبرای انتشار چندین مهندس متخصص مجزا وجود دارد، اما برای اکثر تیم‌های گوگل، کار مهندسی انتشار توسط مهندسان نرم‌افزار معمولی انجام می‌شود.هدف گوگل، انتشار نرم‌افزارهای مکرر - هفتگی، دو هفته‌ای یا حتی روزانه برای برخی تیم‌ها - از طریق اتوماسیون گسترده فرآیندهای انتشار است. این چرخه انتشار سریع، انگیزه مهندس را افزایش می دهد و با فعال کردن تکرارهای بیشتر سرعت توسعه را تسریع می کند. انتشار مکرر به معنای فرصت های بیشتر برای بازخورد و پاسخ به موقع به آن بازخورد است که کیفیت و ارتباط نرم افزار را افزایش می دهد.فرآیند انتشار گوگل با راه‌اندازی یک فضای کاری جدید و استفاده از آخرین buildهای مطمئن به عنوان پایه برای ایجاد release branch آغاز می‌شود. سپس مهندس انتشار ممکن است به روز رسانی های خاصی را برای گنجاندن در این branch انتخاب کند. در ادامه این نرم افزار به صورت جامع بازسازی و تست می شود. اگر هر مشکلی شناسایی شود، برطرف می‌شود و به‌روزرسانی‌ها به branchانتشار اضافه می‌شوند و سپس یک دور دیگر build و آزمایش انجام می‌شود. این چرخه تا زمانی ادامه می‌یابد که نرم‌افزار تمام تست‌ها را پشت سر بگذارد و در این مرحله برای انتشار پکیج می‌شود. این فرآیند تا حد زیادی خودکار است و به مهندس انتشار اجازه می‌دهد آن را با دستورات ساده یا از طریق یک رابط کاربر پسند مدیریت کند و آماده‌سازی انتشار را ساده‌تر کند.هنگامی که یک build کاندید پکیج شد، معمولاً برای تست یکپارچه سازی بیشتر توسط مجموعه کوچکی از کاربران (گاهی اوقات فقط تیم توسعه) روی یک سرور "stage" بارگذاری می شود.تکنیکی که توسط Google به کار می‌رود شامل mirror کردن بخشی از درخواست‌های کاربران live به یک سرور stage است، در حالی که درخواست‌های واقعی توسط سرورهای productionپردازش می‌شوند. پاسخ‌های سرور stageاستفاده نمی‌شود، اما این راه‌اندازی به Google اجازه می‌دهد تا بررسی کند که چگونه محیط استیجینگ، ترافیک واقعی را مدیریت می‌کند. این روش به شناسایی و حل مشکلات احتمالی، مانند خرابی سرور، در مرحله قبل از تأثیرگذاری بر محیط تولید کمک می‌کند و از ثبات و قابلیت اطمینان در استقرارهای زنده اطمینان می‌دهد.پس از تست اولیه، گوگل معمولاً به استقرار به‌روزرسانی‌ها روی سرورهای «قناری» می‌رود که ترافیک واقعی کاربر را در مقیاس کوچک‌تر مدیریت می‌کنند. این مرحله امکان آزمایش مستقیم تغییرات را با کاربران واقعی فراهم می‌کند، اما تأثیر بالقوه را محدود می‌کند. در صورت موفقیت آمیز بودن، به‌روزرسانی به تدریج در طول چند روز در تمام سرورهای مراکز داده، به‌ویژه برای سرویس‌های حیاتی ارائه می‌شود. این رویکرد مرحله‌ای با هدف به حداقل رساندن اختلالات ناشی از باگ‌های کشف‌نشده احتمالی، تضمین انتقال روان به نسخه جدید است.1-9 تایید راه اندازیقبل از اینکه Google بتواند تغییرات قابل مشاهده برای کاربران یا به‌روزرسانی‌های قابل توجه طراحی را منتشر کند، این تغییرات باید توسط سهامداران مختلف فراتر از تیم مهندسی اصلی تأیید شود. این فرآیند بررسی کامل، انطباق با استانداردهای قانونی، حریم خصوصی، امنیت، و قابلیت اطمینان و سایر الزامات را تضمین می کند. این شامل بررسی های مربوط به پایبندی به اهداف تجاری و گنجاندن مکانیسم هایی مانند نظارت خودکار برای مسائلی مانند قطع شدن سرور است، اطمینان از اینکه به روز رسانی قوی و مطابق با سیاست های شرکت و انتظارات کاربر است.گوگل از یک ابزار داخلی تخصصی برای مدیریت و پیگیری فرآیند بررسی و تأیید برای راه اندازی محصول استفاده می کند. این ابزار تضمین می‌کند که هر محصول به رویه‌های راه‌اندازی خاص خود، از جمله بررسی‌های انطباق و تأییدیه‌ها پایبند است. به گونه‌ای طراحی شده است که انعطاف‌پذیر باشد و امکان سفارشی‌سازی برای نیازهای مختلف محصولات یا مناطق مختلف را فراهم کند، بنابراین فرآیند راه‌اندازی را ساده‌تر می‌کند و در عین حال استانداردهای بالایی را برای هر نسخه حفظ می‌کند.1-10 پس از فاجعه یا مرگ (Post-mortems)پس از یک قطعی یا مشکل قابل توجه در سیستم های production، پرسنل درگیر باید یک سند Post-mortems جمع آوری کنند. این گزارش جزئیات این حادثه را شامل ماهیت، اثرات، توالی رویدادها، علل ریشه‌ای و پاسخ‌های مؤثر و غیرمؤثر آن است. تاکید بر درک موضوع و راهبردهای پیشگیری، اجتناب از سرزنش شخصی است. با اندازه‌گیری زمان خرابی، اختلالات خدمات و پیامدهای مالی، تأثیر قطعی را ارزیابی می‌کند. این سند همچنین جدول زمانی حادثه را از شروع تا حل مشخص می کند و ارزیابی می کند که چه اقداماتی در رسیدگی به مشکل موفق بوده یا نه. درس‌های آموخته‌شده برای راهنمایی بهبودهای آینده و به حداقل رساندن بازگشت، با اقدامات بعدی خاص برای رفع کاستی‌های شناسایی‌شده مشخص می‌شوند.1-11 بازنویسی های مکررگوگل به طور مکرر نرم افزار خود را به روز می کند، معمولاً هر چند سال یک بار آن را بازنویسی می کند تا اطمینان حاصل کند که با پیشرفت های تکنولوژیکی و نیازهای در حال تکامل کاربر مطابقت دارد.در حالی که بازنویسی منظم نرم افزار بخش قابل توجهی از منابع Googleرا مصرف می کند، این استراتژی است که مزایای کلیدی را برای چابکی و موفقیت پایدار شرکت ارائه می دهد. با تکامل فناوری و نیازهای کاربر، نیازهای نرم افزار تغییر می کند و برنامه های قدیمی را کارآمدتر یا مرتبط تر می کند. نرم‌افزار بازنویسی نه تنها پیچیدگی‌های قدیمی را حذف می‌کند، بلکه پایگاه کد را نیز جوان‌سازی می‌کند و اطمینان می‌دهد که نیازهای فعلی را برآورده می‌کند. این فرآیند همچنین اعضای جدیدتر تیم را درگیر می‌کند و حس مالکیت و بهره‌وری را القا می‌کند، زیرا مهندسان انگیزه بیشتری برای کار روی کدهایی دارند که آنها را متعلق به خود می‌دانند. به‌علاوه، بازنویسی‌های مکرر محیطی پویا را ایجاد می‌کند که در آن مهندسان بین پروژه‌ها حرکت می‌کنند، تبادل ایده‌ها را ترویج می‌کنند و اطمینان می‌دهند که نرم‌افزار Google از آخرین پیشرفت‌ها و روش‌های فناوری استفاده می‌کند.2 مدیریت پروژه2-1 بیست درصد زمانگوگل به مهندسان اجازه می‌دهد تا ۲۰ درصد از زمان خود را به پروژه‌های مورد نظر خود اختصاص دهند و فرهنگ اعتماد و نوآوری را تقویت کنند. این سیاست مزایای متعددی دارد: کاوش و توسعه ایده‌های جدیدی را که در غیر این صورت ممکن است مورد توجه قرار نگیرند را امکان‌پذیر می‌سازد، شفافیت پروژه‌های نوآورانه را برای مدیریت تضمین می‌کند، با اجازه دادن به مهندسان برای کار بر روی پروژه‌های پرشور در کنار وظایف معمول، از فرسودگی جلوگیری می‌کند و به طور قابل توجهی بهره‌وری و انگیزه را افزایش می‌دهد. علاوه بر این، این روش فرهنگ نوآوری را در شرکت ترویج می کند، زیرا مهندسان از دیدن همکاران خود در پروژه های خلاقانه و تجربی الهام می گیرند. به طور کلی، قانون 20 درصد یک رویکرد استراتژیک برای پرورش استعدادها و تشویق نوآوری مستمر در گوگل است.2-2 اهداف و نتایج کلیدی (OKR)در Google، افراد و تیم‌ها موظف هستند اهداف روشنی را تعیین و مستند کنند، سپس پیشرفت خود را به سمت این اهداف از طریق اهداف فصلی و سالانه دنبال کنند. این اهداف با نتایج کلیدی قابل اندازه‌گیری و همسویی با اهداف گروهی و کلی شرکت، کمیت می‌شوند. پیشرفت در پایان هر کوارتر ارزیابی می شود و هر گل در مقیاسی از 0.0 تا 1.0 به ثمر می رسد که نشان دهنده میزان تکمیل است. اگرچه این اهداف و نتایج کلیدی (OKR) و امتیازات آن‌ها عموماً در گوگل شفاف هستند، اما مستقیماً برای ارزیابی عملکرد استفاده نمی‌شوند. این سیستم همسویی اهداف را در سطوح مختلف سازمان تضمین می کند و فرهنگ مسئولیت پذیری و پیگیری پیشرفت را ترویج می کند.رویکرد گوگل برای تعیین اهداف و نتایج کلیدی (OKR) از هدف گذاری جاه طلبانه با هدف میانگین نمره ایده آل 65 درصد حمایت می کند. این تیم ها را تشویق می کند تا حدود 50٪ بیشتر از آنچه که ممکن است به طور واقعی به آن دست یابند، کارهایی را هدف قرار دهند. تیم هایی که از این هدف بهتر عمل می کنند، انگیزه بیشتری برای هدف گذاری در سه ماهه بعدی دارند، در حالی که به آنهایی که امتیازهای زیر را کسب می کنند، توصیه می شود OKRخود را طوری تنظیم کنند که دست یافتنی تر باشد و از تعادل بین جاه طلبی و عملی بودن در هدف گذاری اطمینان حاصل کنند.موضوع OKRها در Googleبه عنوان ابزاری حیاتی برای ترسیم و انتقال اهداف در سراسر شرکت عمل می‌کنند و فرهنگ عملکرد بالا را از طریق مشوق‌های اجتماعی پرورش می‌دهند. اگرچه OKRها مستقیماً بر بررسی عملکرد یا جبران خسارت تأثیر نمی‌گذارند، آگاهی از اینکه دستاورد آنها در جلسات تیم بررسی و امتیازدهی می‌شود، مهندسان را برای برتری انگیزه می‌دهد. با تنظیم نتایج کلیدی واضح، عینی و قابل اندازه‌گیری، OKRها تمایل کارکنان را برای عملکرد خوب به سمت فعالیت‌هایی هدایت می‌کنند که به‌طور محسوسی اهداف جمعی شرکت را پیش می‌برد و اطمینان حاصل می‌کند که تلاش‌ها همسو و تاثیرگذار هستند.2-3 تایید پروژهدر حالی که گوگل فرآیند روشنی برای تایید راه اندازی دارد، این شرکت فاقد یک سیستم یکسان برای تایید یا لغو پروژه ها است. تصمیم گیری در سازمان متفاوت است و مدیران در سطوح مختلف در مورد پروژه های تیم خود صلاحدید خود را اعمال می کنند. در برخی موارد، تصمیمات پروژه از پایین به بالا گرفته می شود و به مهندسان امکان می دهد پروژه های خود را انتخاب کنند. برعکس، در سناریوهای دیگر، تصمیمات از بالا به پایین است و مدیران یا مدیران جهت پروژه، تخصیص منابع و لغو را تعیین می کنند. این انعطاف پذیری در مدیریت پروژه نشان دهنده رویکرد متنوع گوگل به نوآوری و نظارت بر پروژه است.2-4 سازماندهی مجدد شرکت هادر Google، تصمیمات اجرایی می‌تواند منجر به لغو پروژه‌های بزرگ یا ادغام پروژه‌های پراکنده جغرافیایی شود و مهندسان را ملزم به یافتن نقش‌ها یا تیم‌های جدید کند. در طول چنین سازمان‌دهی‌هایی، مهندسان معمولاً این آزادی را دارند که موقعیت‌های جدید را در محل خود انتخاب کنند یا در موارد ادغام، گزینه جابجایی برای ادامه تیم فعلی خود را دارند. سازمان‌دهی مجدد شرکت‌ها، از جمله ادغام یا تقسیم تیم‌ها و تغییرات در ساختارهای گزارش‌دهی، در Google نسبتاً رایج هستند. این تنظیمات برای حفظ کارایی و انطباق با فناوری‌ها و الزامات در حال تحول ضروری تلقی می‌شوند، با هدف جلوگیری از تأثیرگذاری بیش از حد ساختار سازمان بر طراحی و عملکرد محصولاتش.2-5 هفته‌های hackسالانهگوگل با میزبانی سالانه hackathons یک هفته ای، نوآوری را تقویت می کند و به مهندسان اجازه می دهد از وظایف معمول خود برای توسعه پروژه های جدید منحرف شوند. این رویدادها با جلسه ای شروع می شوند که در آن ایده ها مطرح می شوند و منجر به تشکیل تیم‌هایی می شود که روی ایجاد دمو یا نمونه های اولیه کار می کنند. نقطه اوج هفته یک جلسه ارائه است که در آن پروژه‌ها به نمایش گذاشته می‌شوند و جوایز کوچکی اعطا می‌شوند، اگرچه بزرگترین پاداش این است که یک پروژه hackathonsبه یک پروژه در مقیاس کامل تبدیل شود. علیرغم تشویق رسمی، مشارکت واقعی به دلیل تقاضاهای شغلی روزانه نسبتاً کم است، با 5 تا 20٪ از مهندسان شرکت می کنند، اگرچه بسیاری دیگر به ارائه های اولیه و پایانی علاقه نشان می دهند و از نوآوری های نمایش داده شده الهام می گیرند.3 مدیریت افراد3-1 نقش‌هاگوگل مسیرهای شغلی متمایزی برای مهندسی و مدیریت دارد که به وضوح نقش رهبران فناوری را از مدیران متمایز می کند. این ساختار همچنین تحقیقات را مستقیماً در تیم‌های مهندسی ادغام می‌کند و از طریق نقش‌هایی مانند مدیران محصول، مدیران پروژه، و مهندسین قابلیت اطمینان سایت (SREs)، پشتیبانی جامع را فراهم می‌کند و فرهنگ قوی نوآوری را تقویت می‌کند. در حوزه مهندسی، گوگل نقش‌های مختلفی را ارائه می‌کند که هر کدام دارای یک پیشرفت شغلی تعریف‌شده، از جمله سطوح متعدد و فرصت ارتقاء هستند، که با مزایایی مانند افزایش حقوق همراه است. این رویکرد شناخت عملکرد را تضمین می کند و از توسعه شغلی در شرکت پشتیبانی می کند.نقش‌های اساس عبارتند از:3-1-1 مدیر مهندسان یا Engineering Managerمدیران مهندسی در گوگل، اغلب با پیشینه مهندسان نرم افزار، نقش اصلی مدیریت افراد در شرکت را تشکیل می دهند که دارای مهارت های فنی و بین فردی هستند. برخلاف مدیران فنی، که بر هدایت جهت فنی پروژه ها تمرکز می کنند، مدیران مهندسی بیشتر درگیر مدیریت افراد از جمله انتخاب رهبران فنی، نظارت بر عملکرد تیم، مربیگری، توسعه شغلی، ارزیابی عملکرد و جنبه های پاداش و استخدام هستند. به طور معمول، یک مدیر مهندسی بر 3 تا 30 نفر نظارت می کند که 8 تا 12 نفر رایج ترین محدوده هستند. این تعیین تمایز واضح بین توسعه پروژه پیشرو و پویایی تیم مدیریت را تضمین می کند.3-1-2 مهندسان نرم افزار یا (SWE)نقش مهندس نرم‌افزار در میان کسانی که توسعه نرم‌افزار را در گوگل انجام می‌دهند رایج‌ترین نقش است، جایی که معیارهای انتخاب به‌طور مشخص برای اطمینان از خروجی‌های با کیفیت بالا و مشکلات نرم‌افزاری کمتری سخت‌گیرانه هستند. Googleمسیرهای شغلی متمایزی را برای مهندسی و مدیریت حفظ می‌کند و به مهندسان نرم‌افزار اجازه می‌دهد بدون اینکه لزوماً نقش‌های مدیریت افراد را بر عهده بگیرند، پیشرفت کنند. رهبری در سطوح ارشد به طور گسترده تعریف شده است، از جمله کمک های قابل توجهی به توسعه نرم افزار، افراد با تخصص فنی قوی اما تمایل کمتری به مدیریت را قادر می سازد تا شغل خود را ارتقا دهند. این رویکرد از سناریویی که اغلب در سازمان‌های دیگر دیده می‌شود، جلوگیری می‌کند، که در آن افراد نقش‌های مدیریتی را صرفاً برای پیشرفت شغلی دنبال می‌کنند و این امر به‌طور بالقوه به قیمت از دست دادن رهبری مؤثر تیم انجام می‌شود.3-1-3 محققان یا Research Scientistگوگل استانداردهای استخدامی بسیار بالایی را برای نقش دانشمند پژوهشی تعیین می کند و نه تنها به یک سابقه اثبات شده در تحقیقات، همانطور که توسط انتشارات نشان داده شده است، بلکه همچنین مهارت کدنویسی را می طلبد. علیرغم واجد شرایط بودن بسیاری از دانشگاهیان برای موقعیت های مهندسی نرم افزار، همه نمی توانند معیارهای یک دانشمند پژوهشگر در گوگل را برآورده کنند. دانشمندان پژوهشگر و مهندسان نرم افزار در گوگل در حالی که عناوین متمایز دارند، مسئولیت های زیادی از جمله انجام تحقیقات اصلی، توسعه فناوری های جدید و نوشتن کد را به اشتراک می گذارند. این همکاری که اغلب روی پروژه‌های مشابهی با هم کار می‌کنند، ادغام یکپارچه تحقیقات نوآورانه را در محصولات کاربردی و آماده بازار تسهیل می‌کند، که نمونه‌ای از رویکرد Googleبرای ترکیب تحقیقات با مهندسی است.3-1-4 مهندسان اطمینان سایت یا Site Reliability Engineerدر Google، تعمیر و نگهداری سیستم‌های عملیاتی توسط تیم‌های مهندسی نرم‌افزار به جای مدیران سیستم سنتی انجام می‌شود و مهندسان قابلیت اطمینان سایت (SRE) نقش کلیدی را ایفا می‌کنند. معیارهای موقعیت‌های SREبا معیارهای مهندسین نرم‌افزار کمی متفاوت است و به طیف وسیع‌تری از تخصص اجازه می‌دهد. در حالی که سطح مهارت مهندسی نرم افزار مورد نیاز برای SRE ها ممکن است انعطاف پذیرتر باشد، این می تواند با دانش قوی در زمینه هایی مانند شبکه یا سیستم یونیکس متعادل شود. مشخصات نقش SRE و اهمیت آن به طور گسترده در کتاب SREشرح داده شده است و عملکرد مهم آن را در چارچوب عملیاتی Google برجسته می کند.3-1-5 مدیر محصولمدیران محصول در گوگل نقش مهمی در نظارت بر توسعه و مدیریت محصولات دارند. آنها در نقش حامیان کاربر، مهندسان نرم‌افزار را با اولویت‌بندی ویژگی‌ها، همکاری با تیم‌های دیگر، مدیریت باگ‌ها و زمان‌بندی‌ها، و اطمینان از در دسترس بودن تمام منابع لازم برای ایجاد محصولات با کیفیت بالا راهنمایی می‌کنند. در حالی که معمولاً در کدنویسی دخالتی ندارند، مدیران محصول از نزدیک با مهندسان کار می کنند تا اطمینان حاصل کنند که توسعه با دیدگاه محصول و نیازهای کاربر همسو است.3-1-6 مدیر برنامه یا برنامه فنی Program Manager / Technical Program Managerمدیران برنامه در Google، دقیقاً مانند مدیران محصول، به جای خود محصولات، بر اجرای پروژه‌ها، فرآیندها یا عملیات نظارت می‌کنند و بر جنبه‌هایی مانند جمع‌آوری داده‌ها تمرکز می‌کنند. مدیران برنامه های فنی، زیرمجموعه ای از این نقش، با نیازشان به مهارت های فنی خاص مرتبط با پروژه هایشان، مانند تخصص زبان شناسی برای پروژه های داده گفتاری، متمایز می شوند. نسبت مهندسان نرم‌افزار به مدیران محصول و برنامه در Googleنسبتاً بالا است، معمولاً از 4:1 تا 30:1 متغیر است، که نشان‌دهنده تأکید شدید بر مهندسی در چارچوب مدیریت پروژه و محصول شرکت است.4 امکاناتمحل کار Google به گونه ای طراحی شده است که هم سرگرم کننده و هم کاربردی باشد و دارای امکاناتی مانند سرسره، گودال توپ، اتاق بازی، کافه رایگان، و «میکرو آشپزخانه» است که تنقلات و نوشیدنی های رایگان ارائه می دهد که به جذب و حفظ استعدادها کمک می کند. این فضاها نه تنها کارمندان را تشویق می کنند که مدت بیشتری در محل کار بمانند، بلکه تعاملات غیررسمی و اشتراک ایده را نیز تقویت می کنند. امکانات اضافی مانند سالن های ورزشی، ورزش، و خدمات ماساژ باعث ارتقای سلامت و شادی، افزایش بهره وری و حفظ کارمندان می شود. طرح دفتر برای تسهیل ارتباطات، علیرغم تأثیرات بالقوه بر تمرکز، طرح باز است. صندلی‌ها اختصاص داده می‌شوند، اما اغلب برای تشویق تعامل‌های جدید تغییر می‌کنند. علاوه بر این، اتاق‌های جلسه مجهز به فناوری کنفرانس ویدیویی پیشرفته برای ارتباط یکپارچه هستند که نشان‌دهنده تعهد Google به یک محیط کاری مشترک و نوآور است.4-1 آموزشگوگل تاکید زیادی بر آموزش کارکنان دارد و فرصت‌های یادگیری مختلف و ساختارهای پشتیبانی را برای نیروی کار خود فراهم می‌کند. این شامل آموزش اجباری برای استخدام‌های جدید، معروف به "Nooglers" و "Codelabs" برای کارکنان فنی است تا از طریق دوره‌های آنلاین مختصر، در مورد فناوری‌های خاص بیاموزند. علاوه بر این، Google طیف گسترده‌ای از دوره‌های آموزشی آنلاین و حضوری را ارائه می‌دهد و از آموزش‌های بیشتر در مؤسسات خارجی پشتیبانی می‌کند. برای کمک به ادغام و یادگیری، به کارمندان جدید یک «مرشد» رسمی برای راهنمایی و یک «رفیق» برای حمایت غیررسمی‌تر اختصاص داده می‌شود که با راهنمایی‌های غیررسمی از طریق تعامل با مدیران، شرکت در جلسات بررسی تیم و کد، و سایر فرآیندهای غیررسمی محل کار تکمیل می‌شود.4-2 ارزیابی عملکرد و پاداشگوگل برای بازخورد در میان کارمندان خود ارزش زیادی قائل است و فرهنگ شناخت را از طرق مختلف پرورش می دهد. مهندسان و کارمندان می‌توانند برای کار یا مشارکت‌های استثنایی «peer bonuses» و «kudos» به یکدیگر اعطا کنند، با پاداش‌های همتا که 100 دلار مشوق نقدی ارائه می‌کنند و تجلیل به عنوان ستایش غیرپولی ارائه می‌شود. به‌علاوه، مدیران این اختیار را دارند که برای دستاوردهای خاص، جوایزی بدهند. فرآیند ارتقاء Google کامل است، شامل نامزدهای شخصی، بررسی همتایان و مدیران، و تصمیمات کمیته، با مکانیسم‌هایی برای تجدیدنظر. این شرکت از طریق برنامه‌های بهبود هدفمند، عملکرد ضعیف را برطرف می‌کند، که خاتمه آن یک نتیجه نادر است. کیفیت مدیریت نیز از طریق نظرسنجی های دوسالانه کارکنان، حصول اطمینان از پاسخگویی و فرصتی برای بهبود مدیریت ارزیابی می شود. این سیستم بازخورد و شناسایی جامع، کلید تلاش Google برای ایجاد انگیزه و حفظ استانداردهای بالا در میان نیروی کار خود است.آدرس لینکدین:https://www.linkedin.com/in/mohammadhosseinjalili/

چگونه یک CTO بشویم

محمد حسین جلیلی — Sun, 07 Apr 2024 19:10:21 +0330
قدم گذاشتن توی مسیر تبدیل شدن به یک CTO نیازمند تشخیص ارزش‌های مختلف فناوری‌هاست. اگر هنوز به این فکر هستید که یک پست وبلاگی در مورد نقاط ضعف PHP یا هر فناوری دیگری بنویسید، این یک نشانه‌ای است که شاید آماده ورود به این مسیر نباشید. رهبری واقعی به معنیه بهره‌برداری از نقاط قوت هر ابزار است، نه فقط برجسته کردن نقاط ضعف اون.تبدیل شدن به یک CTO به این معنی نیست که بهترین کد نویس یا هکرترین هکر موجود در جهان باشید.در واقع، نوشتن کد احتمالا آخرین چیزی است که یک CTO شاید انجام بدهد. به جای این، CTO شخصی است که توانمندی تجزیه و تحلیل فناوری‌ها را دارد و می‌تواند آن‌ها را به اعضای تیم انتقال دهد و آن‌ها را در انجام پروژه هدایت ‌کند. CTO از تیم فناوری در برابر هرج و مرج‌های خارجی محافظت می کند و زمانی که همه چیز جهت می‌گیرد، در مقابل خطا‌ها و مشکلات فناوری مسئولیت قبول می‌کند.شاید بشه به راحتی و تصادفی با استخدام توی یک شرکت کوچیک و بدون برنامه نویس، CTO شد، مثل حالت‌هایی که در اکثر استارتاپ‌ها دیده می‌شه. اما در حالی که عنوان ممکن است «مدیر ارشد فناوری» باشد، احتمالاً فقط یک مخفف شیک برای «برنامه نویس پرکار» هست. ولی این مسئله می‌تونه خودش باعث بشه که نیاز پیدا کنیم که چگونه باید مسیر CTO شدن رو طی کنیم.من به شخصه پذیرشی از تیم‌هایی که همه‌ی دارایی‌های استراتژیک فناوری رو از تیم‌های دیگه کپی گرفته‌اند، ندارم. با ارجاع به Camille Fournier که در "در مورد نقش CTO" توضیح می دهد، یک CTO باید اطمینان پیدا کند که تیم فناوری بدون ورودی یا ایده‌های نوآورانه‌ی خودش چیزی را اجرا نمی کند. این موضوع به رهبری CTO بر می‌گردد، شخص CTO باید تجربه و تخصص خودش و تیمش رو خوب بشناسه و اون‌ها رو ارتقاء بدهد.یه موضوعی که خیلی سخته و من عمیقا حسش کردم 😓 موضوع ایجاد تعادل بین فرهنگ نوآوری و هم سویی تصمیم گیری‌های این فرهنگ و انتخاب‌هاش با استراتژی‌های کسب و کاره.این جوری که استراتژیست‌های لایه‌ی کسب و کار چیزای مختلفی می‌خوان (( اونا هم مقصر نیستند ولی خب مجبورند دیگه 🥴)). اینجوریه که برای پول گرفتن از آدما باید بازیشون بدی و پیچیدگی‌ها و بیچارگی‌های تیم توسعه و فناوری و بقیه از همینجا شروع می‌شه. البته این بیشتر توی کسب‌هایی که وابستگی ندارند صدق می‌کنه! 🤠اگر شرکتی به یک CTO یا مدیر ارشد فنی نیاز داشته باشه، اون شخص به تعریف چشم انداز تأثیر بلندمدت بر فناوری می‌پردازه. امروزه اینجوری نیست که بیشتر کسب و کارهای از فناوری استفاده کنند، بلکه حتی بیشتر توسط فناوری تعریف می شوند. به طور خلاصه، نقش در حال تحول CTO نشان دهنده اهمیت فناوری در تعریف و هدایت موفقیت کسب و کارهای مدرن هست. CTO نه تنها چشم انداز فناوری را تعیین می کند، بلکه تضمین می کند که شرکت به طور مداوم نوآوری دارد و از فناوری به عنوان ستون اساسی استراتژی تجاری و مزیت رقابتی خود استفاده می کند.مثلا یک استارتاپ رو در نظر بگیرید که هدفش ارائه‌ی سرویس‌های نوآورانه در حوزه مالی یا fintech هست، حالا نقش CTO خیلی حساس می‌شه.در این فضا یه CTO نمی‌تونه کنار بکشه و بذاره که تیم سر خود، تکنولوژی‌ای را انتخاب و اجرا کنند،😤 دلیلش هم اینه که آخرش CTO مسئولیت پاسخ گویی را دارد.😑یکی از چالش‌های مشترک CTO‌ها، مبارزه بر سر فناوری و توسعه‌ی آن هست!مثلاً) قانع کردن هیت مدیره شرکت برای تست‌های مختلف! ((غالباً این افراد فرآیند‌های فروش را خیلی اهمیت می‌دهند و CTOها باید بتونند موضوعات فناوری را خوب به دیگر قسمت‌های شرکت ارائه دهند و منابع برای فناوری جذب کنند.))یک CTO واقعی باید قدرت تصمیم‌گیری فنی و اجرای اون رو بدون نیاز به تأیید یا اجماع از بخش‌های غیرفنی سازمان داشته باشد، و اینجا هم یک نقطه تمایز یک CTO و مهندس ارشد هست.👊در کل اقتدار و نقش CTO در سازمان یا شرکت بسیار پر اهمیت هست.مدیر ارشد فناوری یا CTO یک شغل یا یک موقعیت در لایه‌ی استراتژی کسب و کار است که جهت فناوری در داخل یک شرکت یا سازمان را مشخص می کند. اگرکه از جلسات، تعامل با افراد غیر فنی متنفر هستید و فکر می‌کنید که همه مدیران تمام روز می نشینند و کاری انجام نمی دهند، این شغل مناسب شما نیست. اما اگر که این موضوعات برای شما مشکلی به همراه ندارد، می‌توان همه اینها را آموخت، به ویژه از آنجایی که کتاب های بسیار خوبی برای کمک کردن به شما وجود دارد. هر جلسه بحثی است در مورد مسیری که کسب و کار در آن در حال حرکت است و اینکه چگونه فناوری می تواند به آن کمک کند، یا گاهی اوقات چگونه فناوری می تواند فرصت های جدیدی برای رشد ایجاد کند. همه اینها باید به زبان ساده توضیح داده شود، به نحوی که برای همه قابل درک باشد.🤩 هر حال جلسه زیاد دارید بنابراین درک نیازهای کسب و کار و مشتریان ضروری است. از تجربه من:بسیاری از افراد فنی دوست دارند از "موضوعات کسب‌و‌کار" فاصله بگیرند. با این حال، این اولین چیزی است که باید به عنوان یک CTO بدانید. هیچ تصمیم فنی نباید در خلاء نگرانی‌های صرفاً نرم افزاری یا سخت افزاری اتفاق بیفتد. در بیشتر مواقع CTO باید با مدیران محصول همراه باشد تا این که استراتژی محصولات با عملیات توسعه، سازگار باشند.در نهایت CTO باید محیطی را ایجاد می کند که به تیم اجازه می دهد به چیزهای بزرگ دست یابد. امروزه بخش بزرگی از مشکلات مربوط به استخدام است. همه به دنبال توسعه دهندگان هستند، از طرفی هم تعداد آنها بسیار زیاد است، بنابراین محیط باید تا حد امکان، پذیرا باشد. این چیزی است که CTO باید بداند که چگونه آن را به خوبی انجام دهد، چرا که خودش هم یک زمانی یکی از آنها بوده است. اگر تیم بخواهد TDD یا pair programming، یا staging serversرا انجام دهد – باید همه آنها توسط CTO تایید شوند. این موضوعات تغییرات بزرگتری را به همراه خواهند داشت که باید CTO آن‌ها را در نظر بگیرد.و اما رابطه‌ی CTO و موضوعات مالی 🤔:در نظر گرفتن پیامدهای مالی مربوط به عملیات فناوری بسیار مهم است. در حالی که استارت‌آپ‌ها ممکن است انعطاف‌پذیری برای استفاده از جدیدترین فناوری‌ها را داشته باشند، ولی سازمان‌های بزرگتر باید بسیار محتاط‌تر باشند و هر تصمیم را بر اساس بازگشت سرمایه (ROI) ارزیابی کنند. سوال اصلی این است: یک فناوری چقدر برای مشتری ارزش دارد؟ اغلب، این در مورد یافتن تعادل بین به روز رسانی زیرساخت های موجود و اجتناب از دام انجام بازنویسی های گسترده و پرهزینه است. یک استراتژی مهم شامل اعمال قانون 80-20 با هدف دستیابی به 80 درصد از منافع تنها از 20 درصد سرمایه گذاری است.در مواقعی بوده که در برخی از تعاملات نظرات دوستان با سابقه‌ای رو شنیدم، اغلب با سوالاتی مانند "چرا این نسخه قدیمی را ارتقاع و از React.js استفاده نمی‌کنید؟" درک این نکته مهم است که بازنویسی کامل برنامه‌ها، به‌ویژه برای استفاده از فناوری‌های جدید، همیشه بهترین رویکرد نیست. در حالی که مدیریت برنامه های قدیمی می تواند در طول زمان پرهزینه شود، بازنویسی آنها معمولاً ارزش کمی برای مشتری ایجاد می کند. تمرکز باید بر ایجاد توازن در تلاش‌های توسعه باشد. گردآوری تیمی که فقط می‌خواهد با جدیدترین فناوری ها کار کند در دراز مدت عملی نیست.این رویکرد چارچوبی را برای اولویت بندی آنچه که بیشتر اهمیت دارد ایجاد می کند. به عنوان مثال، من قابلیت اطمینان و امنیت را اولویت اصلی هر نرم افزاری می دانم. بنابراین، هرگونه تغییر در اهداف کسب‌و‌کار با توجه به این اولویت ها ارزیابی می شود. حریم خصوصی نیز بسیار مهم است، مفهومی که افراد غیر فنی اغلب درک کامل آن را چالش برانگیز می دانند. با این حال، اگر ابتکارات خاصی با استانداردهای حفظ حریم خصوصی مطابقت نداشته باشد، می تواند گزینه های موجود برای یک شرکت را محدود کند. اطمینان از رعایت و مدیریت این مرزها بخش مهمی از نقش من است.تمرکز من روی فناوری است، با این حال معتقدم که باید یکپارچه و seamless باشد. بحث در مورد شایستگی PHP، یا هر فناوری، در نهایت برای من موضوع بی ربطی است. در حالی که برخی ممکن است چنین بحث‌هایی را جذاب بدانند، اما برای یک سازمان اهمیت کمی دارند. فراتر رفتن از این نگرانی‌ها، نقطه عطفی در مسیر تبدیل شدن به یک مدیر ارشد فناوری یا CTO است. این در مورد تغییر توجه از جزئیات فناوری به مسئولیت‌های گسترده تر، از جمله رهبری تیم و اهداف کلان سازمانی است.و در نهایت:یک مدیر ارشد فناوری یا CTO بودن نیازمند دانش گسترده تری از فناوری است، روزانه سوالاتی که در ذهن یک CTO می‌گذرد متفاوت است. دیگر سوالات از جنس مهندسی و فناوری نیست بلکه به خدمت در آوردن فناوری برای موفقیت کسب و کار هست و این نیازمند درک عمیقی از فناوری هست و چشم انداز وسیع تری را می‌خواهد.آدرس لینکدین بنده:https://www.linkedin.com/in/mohammadhosseinjalili/

تهیه‌ی نسخه‌ی پشتیبان با نرم‌افزار clonezilla

محمد حسین جلیلی — Sun, 20 Nov 2022 01:18:52 +0330
1 آشنایی با نرم‌افزار clonezillaنرم‌افزار clonezilla از دسته‌ی نرم‌افزار‌هایی به‌حساب می‌آید که توانایی گرفتن imegeو clone را دارا می‌باشد.دو نوع clone zilla در حال حاضر موجود می‌باشد clonezilla live و clonezilla SE(server edition).نرم افزار Clonezilla live مناسب است برای این‌که شما بخواهید برای یک ماشین استفاده کنید درصورتی‌که clonezilla SE می‌تواند این کار را درد زمانی یکسان انجام داد.1-1 ویژگی‌هاپشتیبان از بسیاری از فایل سیستم‌ها مانندext2, ext3, ext4, reiserfs, reiser4 xfs, , jfs, btrfs and f2fs of GNU/Linux, (2) FAT12, FAT16, FAT32, NTFS of MS Windows, (3) HFS+ of Mac OS, (4) UFS of FreeBSD, NetBSD, and OpenBSD, (5) minix of Minix, and (6) VMFS3 and VMFS5 of VMWare ESX2 نحوه‌ی استفادهنحوه‌ی استفاده از این برنامه را در ادامه با ذکر مثال شرح داده‌شده است.2-1 تهیه‌ی نسخه‌ی پشتیبان[1]در این مثال، ماشین دارای دو disk می‌باشد، به نام‌های sda و sdb.همان گونه که در‏شکل ‏2‑1 مشاهده می‌کنید disk sdaدارای ۴ پارتیشن می‌باشد.شکل ‏2‑1 diskنرم‌افزار clonezilla را به‌صورت bootable دانلود کنید.در قدم بعدclonezilla را در محیط dos بالا بیاورید.بعد از boot شدن نرم‌افزار، شما شکل ‏2‑2 مشاهده می‌کنید. در این مرحله اولین گزینه را انتخاب کنید.این گزینه به صورت پیش‌فرض clonezilla می‌باشد. و رزولوشن را مشخص می‌کند.شکل ‏2‑2 clonezillaدر قدم بعدی شما شکل ‏2‑3 مشاهده می‌کنید در این مرحله گزینه‌ی اول را انتخاب کنید.این صفحه KERNEL MODE SETTING را برای GRAPHIC نمایش می‌دهد.شکل ‏2‑3 انتخاب MODE GRAPHICدر قدم بعد نوبت به انتخاب زبان می‌رسد.شکل ‏2‑4شکل ‏2‑4 انتخاب زبانانتخاب کیبورد: در این قسمت شما می‌توانید تنظیمات کیبورد خود را تغییر دهید، درصورتی‌که قصد انجام چنین عملی را ندارید گزینه‌ی don’t touch keymap را انتخاب کنید.شکل ‏2‑5 تنظیمات کیبورددر این مرحله گزینه‌ی start clonezilla را انتخاب کنید. شکل ‏2‑6انتخاب clonezillaشکل ‏2‑6 انتخاب clonezillaدر مرحله‌ی بعدی device image را انتخاب کنید.شکل ‏2‑7 imageشکل ‏2‑7 imageدر این قسمت شما باید local_dev را انتخاب کنید.شکل ‏2‑8 choose devشکل ‏2‑8 choose devبعد از انتخاب گزینه‌ی ok، شکل ‏2‑9 را مشاهده می‌کنید، در این قسمت نرم‌افزار از شما سؤالی در رابطه با متصل کردن دیسک خارجی می‌پرسد به‌عنوان‌مثال اگر می‌خواهید فایل back up شده را بر روی یک هارد بریزید زمان اتصال هارد به سیستم در این قسمت است (توجه کنید که بعد از اتصال ۵ثانیه صبر کنید بعد کلید enter را فشار دهید)شکل ‏2‑9 افزودن دیسکدر مرحله‌ی بعد دیسک مقصد را انتخاب کنید در این مثال ما دیسک sdb1 را انتخاب می‌کنیم.شکل ‏2‑10شکل ‏2‑10 انتخاب مقصددر قدم بعدی از شما دایرکتوری مخزن[1] را می‌خواهد.منظور مکان ذخیره‌ی فایل پشتیبان است. شکل ‏2‑11شکل ‏2‑11 انتخاب مسیردر قسمت بعد نوبت به مشاهده‌ی پارتیشن‌ها می‌شود. شکل ‏2‑12شکل ‏2‑12 مشاهده‌ی پارتیشندر مرحله‌ی بعد beginner را انتخاب کنید. شکل ‏2‑13شکل ‏2‑13 انتخاب modeدر این قسمت savedisc را انتخاب کنید. شکل ‏2‑14شکل ‏2‑14 نحوه‌ی رفتار با فایلدر این مرحله نامی را برای فایل انتخاب کنید. شکل ‏2‑15شکل ‏2‑15 انتخاب نامانتخاب دیسکی که ما می‌خواهیم در آن ذخیره شود. شکل ‏2‑16شکل ‏2‑16 انتخاب محل ذخیرهدرصورتی‌که احتیاج است که فایل سیستم شما بررسی شود می‌توانید در این قسمت این امکان را فعال کنید در غیر این صورت skip را انتخاب کنید.شکل ‏2‑17شکل ‏2‑17 چک کردن فایل سیستماین قسمت مربوط به بررسی فایل image ذخیره‌شده می‌باشد که درصورتی‌که احتیاج به این کار را ندارید می‌توانید گزینه‌ی skip را انتخاب کنید. شکل ‏2‑18شکل ‏2‑18 بررسی فایل imageقابلیت رمز کردن فایل backup درصورتی‌که نمی‌خواهید فایل backupشما رمز شود no را انتخاب کنید. شکل ‏2‑19شکل ‏2‑19 رمز کردن فایلحالا بر روی enter کلیک کنید.شکل ‏2‑20شکل ‏2‑20 ادامهقبل از انجام image شما یک‌بار دیگر شانس گفتن نه را داریدشکل ‏2‑21شکل ‏2‑21 آخرین شانسدر ادامه ما می‌توانیم که مراحل image گیری را مشاهده کنیم.از MBR به‌وسیله‌ی نرم‌افزار dd فایل image تهیه می‌گردد.نمایش Partition table به‌وسیله‌ی sfdisk و partedداده‌ها به‌وسیله‌ی partimage ,ntfsclone, partclone or ddشکل ‏2‑23شکل ‏2‑24شکل ‏2‑25شکل ‏2‑22شکل ‏2‑22 انجام imageگیریشکل ‏2‑23 انجام imageگیریشکل ‏2‑24 انجام imageگیریشکل ‏2‑25 انجام imageگیریدر این قسمت از فرمان exit و یا logout استفاده کنید.شکل ‏2‑26شکل ‏2‑26 اتمامدر این قسمت poweroff یا reboot را انتخاب کنید. شکل ‏2‑27شکل ‏2‑27 آخرین actionدر این مرحله عمل image گیری تمام‌شده است.شکل ‏2‑28شکل ‏2‑28 اتمام مراحل image گیری3 برگرداندن فایل پشتیباندر این فصل نحوه‌ی برگرداندن فایل پشتیبان را مشاهده خواهیم کرد.[2]در ابتدا نرم‌فزار clonezilla را در محیط dos اجرا کنید و مراحلی که در ادامه گفته‌شده است را انجام دهید.بعد از boot شدن نرم‌افزار، شما شکل ‏3‑1مشاهده می‌کنید. در این مرحله اولین گزینه را انتخاب کنید.این گزینه به‌صورت پیش‌فرض clonezilla می‌باشد. و رزولوشن را مشخص می‌کند.شکل ‏3‑1 مشاهده‌ی اولین صفحهدر قدم بعدی شما شکل ‏3‑2مشاهده می‌کنید در این مرحله گزینه‌ی اول را انتخاب کنید.این صفحه KERNEL MODE SETTING را برای GRAPHIC نمایش می‌دهد.شکل ‏3‑2 انتخاب graphicدر قدم بعد نوبت به انتخاب زبان می‌رسدشکل ‏3‑3شکل ‏3‑3 انتخاب زبانانتخاب کیبورد: در این قسمت شما می‌توانید تنظیمات کیبورد خود را تغییر دهید، درصورتی‌که قصد انجام چنین عملی را ندارید گزینه‌ی don’t touch keymap را انتخاب کنید.شکل ‏3‑4شکل ‏3‑4 تنظیمات کیبورددر این مرحله گزینه‌ی start clonezilla را انتخاب کنیدشکل ‏3‑5شکل ‏3‑5 انتخاب clonezillaدر مرحله‌ی بعدی device image را انتخاب کنید.شکل ‏3‑6شکل ‏3‑6 imageدر این قسمت شما باید local_dev را انتخاب کنید البته شما می‌توانید که از گزینه‌های دیگری مانند samba و ssh server و ... استفاده کنید. شکل ‏3‑7شکل ‏3‑7 choose devبعد از انتخاب گزینه‌ی ok شکل ‏3‑8 را مشاهده می‌کنید در این قسمت نرم‌افزار از شما سؤالی در رابطه با متصل کردن دیسک خارجی می‌کند، به‌عنوان‌مثال اگر می‌خواهید فایل back up شده را بر روی یک هارد بریزید زمان اتصال هارد به سیستم در این قسمت است (توجه کنید که بعد از اتصال ۵ثانیه صبر کنید بعد کلید enter را فشار دهید)شکل ‏3‑8افزودن دیسکبعد از انجام مراحل ذکرشده دیسک‌های موجود mount شده و البته همان‌گونه که گفته شد درصورتی‌که شما دیسک را به سیستم متصل کرده باشید در این زمان mount می‌شود.در قدم بعد شما دیسک‌های mount شده را می‌توانید مشاهده و انتخاب کنید. شکل ‏3‑9به‌صورت معمول درصورتی‌که شما دیسک جدیدی را به دستگاه متصل کنید بانام‌هایی مانند sdb و یا sdc و یا sdd ... .در این گزارش ما دیسکی را اضافه کرده‌ایم که بانام sdb در دستگاه mountشده است.شکل ‏3‑9شکل ‏3‑9 انتخاب مخزندر قدم بعدی شما دیسک را مشاهده خواهید کرد.شکل ‏3‑10شکل ‏3‑10 مشاهده‌ی دیسکدر مرحله‌ی بعدی نرم‌افزار به شما دیسک را با جزئیات نمایش می‌دهد. شکل ‏3‑11شکل ‏3‑11 نمایش جزئیات دیسکدر قسمت بعدی beginner mode را انتخاب کنید. شکل ‏3‑12شکل ‏3‑12 انتخاب modeدر این قسمت شما restordisk را انتخاب کنید.شکل ‏3‑13شکل ‏3‑13 انتخاب restordiskدر قسمت بعد شما فایلی که از قبل image گرفته بودید را انتخاب کنید. شکل ‏3‑14شکل ‏3‑14 انتخاب sourceحال نوبت به انتخاب مقصد یعنی آن دیسکی که می‌خواهیم داده‌ها بر روی آن برگردانیم.شکل ‏3‑15 انتخاب مقصدنرم‌افزار clonezilla از شما سؤال می‌پرسد که آیا می‌خواهید resort را با استفاده از command line انجام دهید.شکل ‏3‑16شکل ‏3‑16 اجرای فرمانقبل از شروع به restore کردن دیسک clone zilla از شما دو دفعه سؤالی را بر مبنای تائید می‌پرسد. شکل ‏3‑17 شکل ‏3‑18شکل ‏3‑17 درخواست تأیید ۱شکل ‏3‑18درخواست تأیید ۲بعد از انجام مراحل بالا نرم‌افزار شروع به بازگردانی فایل isoمی‌کند.شکل ‏3‑19شکل ‏3‑20شکل ‏3‑21شکل ‏3‑19 بازگردانیشکل ‏3‑20 بازگردانیشکل ‏3‑21بازگردانیبعد ا ز اتمام مراحل نرم‌افزار clone zilla از شما می‌پرسد که ‌آیا مایل هستید دوباره نرم‌افزار را اجرا کنید در این‌زمانی شما می‌توانید که فرمان خروج “exit”را وارد کنید.شکل ‏3‑22ل ‏3‑22 ادامهو آخرین پرسش نرم‌افزار از شما این است که ‌آیا می‌خواهید سیستم شما خاموش شود و یا rebootو یا ... شود. شکل ‏3‑23شکل ‏3‑24شکل ‏3‑23 آخرین سؤالشکل ‏3‑24 reboot کردن دیسکبرای تماس با بنده می‌توانید از لینک زیر استفاده کنیدhttps://teaching.iranmodares.com/teaching-index.php?metaword=%D9%85%D8%AD%D9%85%D8%AF+%D8%AD%D8%B3%DB%8C%D9%86+%D8%AC%D9%84%DB%8C%D9%84%DB%8C

لاگ‌ در لینوکس، ESXi و میکروتیک

محمد حسین جلیلی — Sun, 20 Nov 2022 00:30:02 +0330
بررسی syslog در لینوکسبرای این‌که از یک سیستم لینوکسی log بگیریم از چندین نرم‌افزار می‌توانیم استفاده کنیم مانند:syslogrsyslogNG-syslogsyslog-NGand ...برای این‌که ببینیم چه log کننده‌ای بر روی سیستم نصب است از برنامه ‏1‑1 استفاده می‌کنیمps –aef | grep logبرنامه ‏1‑1 سیستم لاگبرای مشاهده‌ی لاگ‌ها وارد مسیر /var/log شده و فایل مربوطه را مشاهده می‌کنیم همچنین می‌توانید از فرمان dmesgهم استفاده کنید [1]1-1 لاگ سیستم(system log)فایل /var/log/syslog حاوی لاگ‌هایی هست که توسط syslogd[1] تولیدشده٬ و این فایل لاگ‌های مهمی را در خود ذخیره می‌کند. واژه‌ی daemenاشاره به اتفاقاتی دارد که در پشت پرده‌ی سیستم‌عامل می‌افتد و از دسترسی و چشم کاربر دور می‌باشد.1-2 لاگ فایل مربوط به شناساییدر مسیر /var/log فایلی بانام auth.log وجود دارد که وظیفه‌ی نگه‌داری اطلاعاتی از قبیل ورود کاربران و اشخاصی که به سیستم متصل شده‌اند را دارد.به‌عنوان‌مثال شما می‌خواهید ببینید که چه شخصی به سیستم sshزده است برنامه ‏1‑2grep sshd /var/log/auth.logبرنامه ‏1‑2 لاگ شناسایی1-3 لاگ‌های پشت پردهدر میسر /var/logفایلی به نام deamen.logوجود دارد همان‌گونه‌ که گفته شد واژه‌ی daeman به آنچه در پشت پرده اجرا می‌شود نسبت داده‌شده است.تفاوت این فایل با syslog در این است که فایل daeman شامل لاگ‌های٬ تمامی اتفاق‌هایی که در پشت صحنه‌ی سیستم‌عامل می‌افتد است مانند سیستمی و نرم‌افزاری ٬ درصورتی‌که syslog چنین نیست و فقط مربوط به اتفاق‌های پشت پرده‌ی سیستم می‌شود و به نرم‌افزارهایی که در پشت پرده اجرا می‌شود کاری ندارد.1-4 لاگ‌های debuggingدر این فایل اطلاعات debugging مربوط به سیستم و نرم‌افزار‌ها وجود دارد.1-5 لاگ‌های هسته یا کرنلدرصورتی‌که شما قصد داشته باشید اتفاقاتی که در kernel می‌افتد را مشاهده کنید می‌توانید به فایل/var/log/kernel.log مراجعه کنید. این فایل شامل اطلاعاتی می‌باشد که در کرنل رخ می‌دهد مانند شناسایی و الحاق سخت‌افزار و درایور٬ همچنین شما می‌توانی با استفاده از فرمان dmesg از اتفاقاتی که در کرنل رخ می‌دهد مطلع شوید.1-6 لاگ فایل‌هایی که مورد استفاده برای نرم‌افزارها هستندبرخی از لاگ‌ فایل‌ها هستند که مورداستفاده‌ی برخی از نرم‌افزار‌ها می‌شوند و نرم‌افزار‌ها با استفاده از ‌آن‌ها به شناسایی و وظیفه‌ی خود می‌پردازند.[2]فایل wtmp یک فایل باینری است که در مسیر /var/log وجود دارد که فرمانم who از این فایل استفاده می‌کند و با استفاده از این فایل به شناسایی افرادی که به سیستم login هستند می‌پردازد.1-7 فرمان‌های پراستفاده برای خواندن لاگدر جدول ‏1‑1 به یک سری از فرمان‌ها اشاره‌شده است که می‌تواند در لاگ خوانی از آن‌ها استفاده کرد.جدول ‏1‑1 فرمان‌های پرکاربرد2 بررسی logها در میکروتیکمیکروتیک این قابلیت را دارد که اتفاق‌هایی که در سیستمش رخ می‌دهد را در مسیری به نام log نمایش دهد٬ اما در این مسیر٬ لاگ‌های متنوعی وجود دارد که در این فصل به اساسی‌ترین‌های آن می‌پردازیم.[3]شما می‌توانید تمامی logهایی را که میکروتیک تولید می‌کند در اینجا مشاهده کنید.لاگ‌هایی که باید در میکروتیک بررسی شوند و از اهمیت بیشتری برخوردار می‌باشند درجدول ‏2‑1 نام‌برده شده.جدول ‏2‑1 پیغام‌ها در میکروتیکمواردی که گفته شد همراه با یک درجه‌بندی مشخص می‌شوند٬ یعنی ممکن است که یک log گزارش‌شده٬ به علت یک error اتفاق افتاده باشد٬ یا این‌که یک log برای اطلاع دادن از یک رخ داد معمول و عادی باشد این درجه‌بندی‌ها در جدول ‏2‑2 ذکر شده است.جدول ‏2 2 درجه‌بندی لاگ‌هانکته) در جدول ‏2‑1 یک سری پیغام‌ها ذکر شد٬ که این دسته از logها مهم بوده و در صورت وجود باید موردتوجه قرار گیرند و علت آن‌ها مشخص شود٬ اما در برخی مواقع٬ برخی از logها باید حتماً بررسی شوند و موضوع‌ آن‌ها مهم نیست٬ بلکه آنچه اهمیت دارد درجه‌بندی logها است. در جدول ‏2‑2 درجه‌بندی اهمیت logها مشخص شد٬ پس به این نکته توجه کنید که هرگونه ‌log تولیدشده که در درجه‌بندی error و warning قرار داشت باید موردتوجه قرار بگیرد و علت آن مشخص شود٬ همچنین logهایی که در دسته‌ critical هستند٬ می‌توانند ما را آگاه کنند٬ که چه اشخاصی به router متصل شده‌اند.3 لاگ در ESXIدر این قسمت قصد درایم که logهای esxi را بررسی کنیم.[4]درجدول ‏3‑1 logهای مهم مربوط به esxi گفته‌شده است و هرکدام توضیح مختصری داده‌شده‌اندجدول ‏3 1 esxi log4 چه لاگ‌هایی را بهتر است که موردتوجه قرار دهیمدر این فصل به بررسی این‌که چه نوع log را در چه زمانی بررسی کنیم می‌پردازیم.در فصل‌های گذشته از این مستند، به بررسی انواع logها پرداخته شد و این موضوع که چه logهایی باید حتماً موردتوجه قرار گیرند مطرح شد، اما در این فصل به بررسی این نکته که چه logهایی باید روزانه بررسی شود و این‌که در چه مواقعی log دستگاه بررسی شود پرداخته می‌شود.در اکثر شرکت‌ها logهای دستگاه‌های مختلف اعم از فایروال، سوئیچ و .. جمع‌آوری می‌شوند نه‌فقط به‌این‌علت که مشکلات به وجود آمده بررسی و برطرف شوند، بلکه از این روش استفاده می‌کنند که در آینده بتوانند با استفاده از اطلاعات به‌دست‌آمده از این منابع انتخاب بهتری داشته باشد از دیگر موارد استفاده می‌توان به مثال زیر را بیان کرد:“در سازمان‌های بزرگ که ارباب‌رجوع‌های بسیاری از طریق شبکه‌ی اینترنت به سازمان متصل می‌شوند و از خدمات سازمان استفاده می‌کنند، به علت بار زیاد ممکن است که مشکلات زیادی به وجود آید.افراد مسئول در پی حل این قبیل مشکل‌ها به دنبال رفع این مشکل‌ها می‌گردند. این افراد با بررسی اطلاعاتی، که از طریق، log فایل‌های خاصی به دست می‌آید، یک دسته اطلاعات آماری،‌ از واکنش دستگاه در برابر میزان loadهای متفاوتی، که بر روی دستگاه‌های حساس شبکه به وجود می‌آید جمع‌آوری می‌کنند و از این اطلاعات در جلسات تصمیم‌گیری استفاده می‌کنند” .در یک سازمان بررسی امنیت بسیار حیاتی و مهم است، بنابراین توصیه می‌شود که هرروزه به بررسی logهای مربوط به اتصال به سیستم پرداخته شود، با انجام چنین کاری شما متوجه خواهید شد که چه شخصی قصد داشته به سیستم متصل شود و این‌که چند بار برای اتصال تلاش کرده است و این کار ازلحاظ امنیت در یک سازمان بسیار کاربردی و کلیدی می‌باشد.مورد دوم در رابطه با بررسی log فایل‌هایی است که به performance دستگاه مربوط می‌شود.بنابراین برای دستگاه‌هایی که اهمیت امنیتی دارند بهتر است که logفایل‌ّهای مربوط به authenticationرا بررسی کنید و درصورتی‌که تجهیزات ازنظر پردازشی اهمیت دارند شما می‌توانید log فایل‌ها مربوط به performance را مشاهده کنید،‌ log فایل‌ها در ابتدای همین مستند بررسی شده و توضیح داده شده‌اند.[5]۵ مراجع[1] “LinuxLogFiles - Community Help Wiki.” [Online]. Available: https://help.ubuntu.com/community/LinuxLogFiles. [Accessed: 07-May-2016].[2] “System log in OpenWrt [OpenWrt Wiki].” [Online]. Available: https://wiki.openwrt.org/doc/howto/log.essentials. [Accessed: 07-May-2016].[3] “Manual:System/Log - MikroTik Wiki.” [Online]. Available: http://wiki.mikrotik.com/wiki/Manual:System/Log. [Accessed: 08-May-2016].[4] “Which ESX log file,” VMwarewolf, 04-Jul-2007. .[5] “Effective-Daily-Log-Monitoring-Guidance.pdf.” .برای تماس با بنده می‌توانید از لینک زیر استفاده کنیدhttps://teaching.iranmodares.com/teaching-index.php?metaword=%D9%85%D8%AD%D9%85%D8%AF+%D8%AD%D8%B3%DB%8C%D9%86+%D8%AC%D9%84%DB%8C%D9%84%DB%8C

آموزش فایروال لینوکس و بررسی فایروال‌های لینوکسی

محمد حسین جلیلی — Sat, 19 Nov 2022 01:22:49 +0330
مقدمهدر این مستند فایروال‌های لینوکسی بررسی خواهد شد.در ابتدا به معرفی توزیع‌هایی از فایروال که با استفاده از سیستم عامل لینوکس تهیه شده‌اند پرداخته می‌شود و بعد از آن به بررسی دقیق ابزار‌ّهای پوشاننده‌یiptables پرداخته می‌شود.در ابتدا به بررسی فایروال‌هایی می‌پردازیم که هسته‌ی آن‌ها، سیستم‌عامل لینوکس است و این گونه می‌توان بیان کرد که این دسته از فایروال‌ها همان لینوکس customizeشده است.تعداد فایر‌وال‌هایی که هسته‌ی آن‌ها سیستم عامل لینوکس است را می‌توانید در آدرس [1] ذکر شده در فصل مراجع مشاهده فرمائید.تعداد زیادی از فایروال‌ّها از سیستم عامل لینوکس به عنوان هسته استفاده کرده اند که در این مستند اختصار به معرفی فایروال‌های· Ipcop· Pfsense· SmoothWall Express· Endian· ClearOS· Monowall· Drawbridge· Ipfire· Alpine Linux· OPNsense· Devil-Linux· Untangle NG Firewall· VyOSمی‌پردازیم.2 توزیع‌هایی از فایروال مبتنی بر لینوکسدر این فصل به معرفی توزیع‌هایی از فایروال‌ها که هسته‌ی آن‌ّها لینوکس است می‌پردازیم.2-1 فایروال IPCOPفایروال ipcop به صورت سیستم عامل موجود است و این فایروال را می‌توان رایگان از سایت آن دانلود کرد و از آن استفاده کرد. این فایروال با هدف فراهم آوردن استفاده‌ی ساده از امکاناتِ یک فایروال طراحی شده است، که بتوان بر روی سخت افزار یک PCنصب و استفاده کرد.مدیریت این فایروال با استفاده از web interface بوده و از زبان فارسی پشتیبانی می‌کند.شکل ‏2‑1شکل ‏2‑1 نمایی از ipcopعمل کرد این فایروال این گونه است که در ابتدا از شما درخواست مشخص کردن نوع شبکه را می‌کند و شبکه‌ها را اینگونه دسته بندی می‌کند:1. شبکه Green: شبکه‌ی داخلی(LAN ) که مطمئن می‌باشد.2. شبکه Blue: شبکه‌ی بیسیمِ مطمئن، که می‌توان به عنوان Green 2 هم از آن استفاده کرد.3. شبکه Orange: این شبکه به عنوان DMZ یا محل قرار گیری web server در نظر گرفته می‌شود .4. شبکه Red: این شبکه همان شبکه‌ی نامطئن یا اینترنت می‌باشد.این شبکه‌ها را می‌توان مانند شکل ‏2‑2 نمایش داد.شکل ‏2‑2 نمایی از شبکه‌های مورد استفاد در IPcopویژگی‌های ipcopرا می‌توان در آدرس [2] ذکر شده در فصل مراجع مشاهده کرد.2-2 فایروال pfsenseفایروال pfsense با هدف firewall/router به صورت متن باز بر اساس Free BSD طراحی شده است. این فایروال به صورت سیستم عامل برروی یک سخت‌افزار یا virtual machine نصب شده و امکان مدیریت شبکه‌ی اختصاصی را به شما می‌دهد.مدیریت این فایروال از طریق web interface فراهم آورده شده است. شکل ‏2‑3شکل ‏2‑3 نمایی از PFsemseویژگی‌های این فایروال در آدرس [3] ذکر شده در فصل مراجع موجود است.2-3 فایروال SmoothWall Expressبرند Smoothwall یک شرکت نرم‌افزاری شخصی است که در کانادا به فیلتر کردن محتوای وب و همچنین به نگهداری و پشتیبانی پروژه‌های smoothwall مشغول است.این محصول به صورت متن باز موجود است و می‌توان از آن بر روی یک ماشین مجازی یا یک سخت افزار استفاده کرد و همچنین دارای رابط کاربر گرافیکی web interface می‌باشد و برای استفاده از این فایروال/روتر احتیاج به دانش لینوکسی بالایی نیست. شکل ‏2‑4شکل ‏2‑4 نمایی از smoothwallویژگی‌های این فایروال در آدرس [4] ذکر شده در فصل مراجع موجود است.2-4 فایروال Endianفایروال endianبا هدف مدیریت یکپارچه‌ی تحدیدات یا UTM طراحی شده است که از شبکه محافظت کرده و ارتباطات را بهبود می‌بخشد که base این فایروال redhat است و به صورت متن باز موجود است دارای ویژگی‌های بسیار زیادی است.شکل ‏2‑5شکل ‏2‑5 نمایی از endianویژگی‌های این فایروال در آدرس [5] ذکر شده در فصل مراجع موجود است.2-5 فایروال clear osفایروال clear os که base آن centos و redhat می‌باشد با هدف قرار گرفتن به عنوان gateway در شبکه‌های کوچک طراحی شده است که برای مدیریت آن یک web interface فراهم امده که به مدیر شبکه امکان پیکربندی را به صورت GUI می‌دهد. در این فایروال در صورتی که نیاز به خرید serviceهای خاص بود می‌توان با پرداخت مبلغی آن‌ها را همراه با پشتیبانی تهیه کرد.این فایروال به صورت رایگان در دسترس می‌باشد و متن باز است. شکل ‏2‑6شکل ‏2‑6نمایی از clear osویژگی‌های این فایروال در آدرس [6] ذکر شده در فصل مراجع موجود است.2-6 فایروال m0n0wallفایروال m0n0wall با هدف جمع کردن ویژگی‌ها و packageهای مورد نیاز فایروال در یک بسته و همچین ساده سازی استفاده از آن‌ها طراحی شده که base آن Free BSD است. پیکربندی در این سیستم فایروال در یک فایل با فرمت XML نگه داری می‌شود که این کار باعث شفافیت درک پیکربندی می‌شود.این فایروال از جمله اولین فایروالی است که در زمان bootپیکربندی خود را با استفاده از PHPانجام می‌دهد و پیکربندی را در یک فایل با فرمت ‌XML انجام می‌دهد. شکل ‏2‑7شکل ‏2‑7 نمایی از monowallویژگی‌های این فایروال در آدرس [7] ذکر شده در فصل مراجع موجود است.2-7 فایروال Ipfireاین فایروال به صورت سیستم عامل موجود می‌باشد که توسط web interfaceقابل پیکربندی بوده و شباهت‌هایی به endian و ipcop در طراحی و رابط کاربری دارد.شکل ‏2‑8 نمایی از ipfireشکل ‏2‑8 نمایی از ipfireویژگی‌های این فایروال در آدرس [8] ذکر شده در فصل مراجع موجود است.2-8 فایروال Alpine Linuxبرند Alpine Linuxیک اجتماع توسعه دهنده و طراح سیستم عامل برای روترهای X86 ، فایروال ، VPNها، VOIP boxesو serverهاست.در این فایروال قابلیت PaXوجود دارد که این قابلیت برای حفاظت از bugهای نرم‌افزار در مقابل exploid است و به صورت patch بر روی کرنل نصب می‌شود.شکل ‏2‑9 نمایی از alpine linuxویژگی‌های این فایروال در آدرس [9]ذکر شده در فصل مراجع موجود است.2-9 فایروال OPNsenseبرند OPNsenseیک سیستم عامل بر مبنای FreeBSDاست که به عنوان یک فایروال و روتر طراحی شده که برگرفته از pfsense است.این پروژه تمرکزش را بر روی پل‌های‌امنیتیِ یکسری ویژگی‌ّهای خاص قرار داده است که این ویژگی‌ها عبارتند از:امکان استفاده از libreSSL به جای OpenSSLشخصی‌سازی شده‌ی مقاوم از ‌BSDفایروال OPNsenseهمچنین دارای یک مکانیزم به روز رسانی‌ امنیتی است.شکل ‏2‑10 نمایی از OPNsenseویژگی‌های این فایروال در آدرس [11] ذکر شده در فصل مراجع موجود است.2-10 فایروالdevil-Linuxفایر وال Devil-Linux یک توزیع لینوکس است که به عنوان روتر/فایروال که بر روی سیستم قابل نصب است استفاده می‌شود.این فایروال به علت نداشتن محیط گرافیکی نسبت به بقیه‌ی فایروال‌ّهای معرفی شده در این مستند، سبک وزن‌تر است.شما می‌توانید در شکل ‏2‑11 نمایی از این فایروال را مشاهده کنید.شکل ‏2‑11 نمایی از devil_linux firewallویژگی‌های این فایروال در آدرس [12] ذکر شده در فصل مراجع موجود است.2-11 فایروال Untangle NG Firewallخود Untangle از دسته‌ نرم‌افزار‌های NGFW/UTM به حساب می‌آید که این فایروال با هدف فراهم آوردن احتیاجاتِ تشکیل یک شبکه اَمن، طراحی شده است.همچنین این فایروال امکان GUI مبتنی بر Web interface را برای مدیریت فایروال دارا می‌باشد. شکل ‏2‑12شکل ‏2‑12 نمایی از فایروال Untangle NGویژگی‌های این فایروال در آدرس [13] ذکر شده در فصل مراجع موجود است.2-12 فایروالVyOSفایروال VyOS به عنوان یک سیستم‌عامل، که نرم‌افزار‌ّهای تحت شبکه را دارا می‌باشد طراحی شده است که با این وجود می‌توان از آن به عنوان فایروال و روتر استفاده کرد.شکل ‏2‑13 نمایی ازVyOSویژگی‌های این فایروال در آدرس [14] ذکر شده در فصل مراجع موجود است.2-13 مقایسهدر می‌توان چندین فایروال که از جهات مختلف بررسی شده‌اند را مشاهده کنید.جدول ‏2‑1 مقایسه‌ی linux firewallجدول ‏2‑1 مقایسه‌ی linux firewall3 ابزار‌هایIPtables’s wrapper[13]در این فصل قصد داریم به بررسی ابزار‌هایی بپردازیم که با استفاده از ماجول IPtables انجام فرایند‌های مورد نیاز شبکه‌ای سیستم را برای ما راحت‌تر می‌کنند و انعطاف پذیری بیشتری به دستورات IPtables می‌دهد.در لینوکس IPtables از ماجول‌ّهای موجود در سیستم عامل لینوکس است که وظیفه‌ی پردازش بسته‌های شبکه‌ را در سیستم لینوکس دارد. البته در آینده ماجول NFtable جایگزین IPtables می‌شود که در موارد زیر با IPtables تفاوت دارد:فناوری NFtable در Syntax نسبت به IPtables طراحی مناسب‌تری را دارا می‌باشد.می‌توان در یک دستور چندین Rule را تعریف کرد که این قابلیت در IPtables وجود ندارد.انعطاف پذیری در NFtableبه دلیل وجود chainهای متفاوت.بهبود performance.جفت مقدار‌های پشت سرهم، عنوان مثال می‌توان چند ip و پورت را با هم ترکیب کرد و در زمانی که احتیاج شد از آن‌ها استفاده کنیم.هوشمندی و پروتکل‌هایی که پشت‌بانی می‌کند بیشتر از iptable است.قابلیت exportکانفیگ به صورت بسیار ساده.به نسخه کرنل جدیدتر از 3.13 نیاز دارد.در این مستند قصد بر آموزش و بررسی دستورات IPtablesو یا NFtables را نداریم بلکه به بررسی ابزار‌هایی می‌پردازیم که از IPtables استفاده می‌کند تا این که نیاز‌های ما را برطرف کند و با بررسی جزئیات آن‌ها از صحت و اَمنیت آن‌ها اطمینان حاصل کنیم.البته iptables بر روی برخی از توزیع‌های لینوکس وجود ندارد مانند FreeBSD که ماجول مخصوص به خود به نام PF را دارند.که ما در این مستند به بررسی این توزیع نمی‌پردازیم.3-1 بررسی Iptablesهمان گونه که گفته شد iptables یک ماجول طراحی شده برای لینوکس است که کار‌های شبکه‌ای مورد نیاز سیستم را فراهم می‌آورد. Iptables برای ارتقاع خود از ماجول‌های دیگری هم استفاده می‌کند که می‌توان این ماجول‌ّها را در آدرس[15] مشاهده کرد.برای استفاده‌ی ماجول‌های گسترش در Iptables می‌توان با استفاده از option –m به همراه نام ماجول از ماجول استفاده کرد. همان‌گونه که گفته شد لیست ماجول‌ها در آدرس [15] آورده شده است و در صورت نیاز کافی است که با مراجعه به این سایت از ماجول‌ّهای گسترش iptables استفاده کنید.اما در ادامه به بررسی ابزار‌ّهایی می‌پردازیم که با استفاده از امکانات iptable یک محیط ساده را برای استفاده از iptables فراهم می‌آورند.3-2ابزار Shorewallابزار Shorewallیک ابزار سطح بالا برای تنظیمات Netfilter است. شما احتیاجات firewall/gateway خود را در یکسری فایل‌ّهای مشخص توصیف می‌کنید. shorewall کانفیگ فایل‌های تنظیم شده را می‌خواند و با استفاده از iptables ، iptables-restore ، tc و ipبه اعمال netfilterمی‌پردازد.ویژگی‌های shorewall:با ضبط ارتباطات netfilterعمل netfilter را به صورت state full [16]انجام می‌دهدمی‌تواند از آن در گستره‌ی وسیعی از router/firewall/gateway application استفاده کردبدون محدودیت در تعداد کارت‌های interfaceتمام پیکربندی توسط پیکر بندی فایل‌های موجود انجام می‌شودامکان zoneبندی شبکه را به شما می‌دهدامکان تخصیص interfaceها به zoneهای مختلفپشتیبانی از مدیریت مرکزی فایروالابزار Shorewall بر روی یک سیستم مشخص نصب می‌شوداسکریپت‌ها اجرایی توسط shorewall کنترل می‌شوددارای quick guid برای راه‌اندازی و تغییرات سریع· محیط گرافیکی آن توسط webmin پشتیبانی می‌شود· پشتیبانی به صورت انعطاف پذیر از مدیریت و route آدرس‌هاویژگی Masquerading/SNATویژگی Portforwarding/DNATویژگی One-to-one NATویژگی Proxy arpویژگی NETMAPویژگی Multi ISP support(پشتیبانی از وجود چندین لینک از طریق Router/Firewallهای یکسان)امکان تشکیل لیست سیاهی از ipهای مورد نظرپشتیبانی از فرمان‌های عمل گرفرمان‌های start, stopn و clear در فایروالامکان ایجاد هشدار صدایی برای زمانی که یک بسته‌ی خاص تنظیم شده دریافت می‌شودگستره‌ی وسیعی از فرمان‌های اطلاعات دهنده‌ی وضعیتویژگی VPN_supportویژگی IPSEC, GRE, IPIP and OpenVPN Tunnelsویژگش PPTP clients and Servers.پشتیبانی از Traffic control/shappingپشتیبانی از توزیع‌های متفاوت گسترده‌ی لینوکسپشتیبانی از RPM و DEbianویژگش Automatically install and updateقابلیت شناسایی MAC آدرسویژگی Traffic accountingپشتیبانی ازBridge/ Firewall· پشتیباتی ازIPv6سازگاری با محیط‌های مجازی سازیویژگیKVMویژگی Xenویژگی Linux-Vserverویژگی OpenVZویژگی VirtualBoxویژگی LXCویژگی Docker (Shorewall 5.0.6 and later)3-2-1 نحوه‌ی استفاده از shorewallبعد از نصب نرم‌افزار بر روی سیستم نوبت به پیکربندی این نرم‌افزار می‌رسد.همان گونه که گفته شد برای پیکر بندی این نرم‌افزار باید با فایل‌ کانفیگ‌های مربوطه کار کنیم، همچنین همان‌طور که گفته شد این نرم‌افزار دارای راهنما‌های زیادی است. در ابتدا می‌توان فایل‌های راهنما را در مسیر برنامه ‏3‑1 مشاهده کرد./usr/share/doc/shorewallبرنامه ‏3‑1 فایل documantهای shorewallهمچنین در شاخه‌ی معرفی شده در برنامه ‏3‑1 می‌توان فایل‌ّهای راهنمای پیکربندی، و نمونه‌هایی از تغییرات فایل کانفیگ را مشاهده کرد.برای کانفیگ shorewall احتیاج است که در ابتدا وارد مسیر /etc/shorewall شوید و کانفیگ فایل مورد نظر را ایجاد کرده و تغییرات را مطابق با راهنمایی‌های موجود انجام دهید، اما این کار مشکل بوده و این که شخص بخواهد نام کانفیگ فایل‌ها و نحوه‌ی تنظیم هر فایل را بداند، کار زمان بری است، اما راه حل این است که در ابتدا در مسیر برنامه ‏3‑2 وارد شده و تمامی و یا فایل‌های لازمه را در مسیر /etc/shorewall کپی کند، خوبی این کار این است که این فایل‌ها دارای نام‌های مورد نیاز است و راهنما‌یی‌های مورد نیاز در داخل فایل برای وارد کردن نحوه‌ی تنظیمات مشخص شده است./usr/share/doc/shorewall/default-configurationبرنامه ‏3‑2 فایل‌های پیش‌فرضنکته‌‌ی قبل از راه اندازی این است که:برای راه اندازی این فایروال در ابتدا باید حداقل ۴ فایل را پیکر بندی کنیم، که این فایل‌ها عبارتند از:1. /etc/shorewall/interfacesدر این فایل باید اینترفیس‌ها مشخص و نامگذاری شوند و این که باید به یک zone نسبت داده شوند برای نمونه شما می‌توانید فایل /usr/share/doc/shorewall/two-interface/example/interface را مشاهده کنید. البته فرمان man shorewall-interface اطلاعات کاملی در این باره به شما می‌دهد.2. /etc/shorewall/policyسیاست‌ّهای مورد نظر در این فایل تعریف می‌شود بعنوان مثال شما می‌توانید دسترسی برای zoneهای مختلف را تعیین کنید. نمونه برای این فایل در مسیر /usr/share/doc/shorewall/two-interface/example/policy موجود است و شما می‌توانید با man shorewall-policy اطلاعات دقیقی به دست آورید.3. /etc/shorewall/rulesدر این قسمت شما می‌توانید قوانین خاص شبکه‌ را پیاده سازی کنید مانند بستن PING راهنماهای این فایل کانفیگ نیز مانند دیگر فایل‌های گفته شده در دسترس است.4. /etc/shorewall/zones در فایل نامگذاری zoneها انجام می‌شودنکته) موارد و نام‌هایی که در فایل‌های گفته شده استفاده می‌کنید مانند نام zone و ... با هم در ارتباط هستند و شما باید از نام‌هایی استفاده کنید که در تمامی فایل‌ها یکسان باشند. بهتر است که از نام‌های گفته شده‌ی خود نمونه فایل‌کانفیگ‌ها استفاده کنید، به عنوان نمونه برای zone محلی از نام loc استفاده کنیم و برای خود zone فایروال از fw استفاده کنیم و برای zone اینترنت از net استفاده کنیم، به این دلیل که برای تغییرات، زمانی که نمونه‌ای از فایل‌کانفیگ را مشاهده می‌کنیم، برای استفاده از آن دچار ابهام نشویم.نحوه‌ی کار کردن با shorewall تا حدودی گفته شد و در این قسمت برای آشنایی بیشتر چندین مثال آورده شده استفرض کنید که یک سیستم با دو اینترفیس داریم و فایل کانفیگ zoneآن را مانند شکل ‏3‑1 قرار داده ایم.شکل ‏3‑1 تعریف zoneدر شکل ‏3‑1 مشاهده می‌کنید که zoneهای متفاوتی تعریف شده است. نام‌های zone عبارنتد از fw, net و loc که نوع آن‌ها هم مشخص شده است.در شکل ‏3‑2 مشاهده می‌کنید که اینترفیس loc و net به دو اینترفیس نصبت داده شده است نام این فایل interface است که زیر شاخه‌ی /etc/shorwallاست.شکل ‏3‑2 نسبت دهی zoneبه اینترفیسشکل ‏3‑3 فایل‌کانفیگ policyرا نمایش می‌دهد که این فایل مشخص کرده کدام zone به کدامیک از zoneهای دیگر ارتباط یا اجازه‌ی ورود داشته باشد.شکل ‏3‑3 نمایی از فایل policyدر شکل ‏3‑3 مشخص شده که دسترسی از شبکه‌ی local به net برقرار باشد و همچنین دسترسی دیگر شبکه‌ها مشخص شده است و البته اخرین policyاین است که تمامی ارتباطاط دیگر rejectشود نکته این جاست اگر که این خط در این فایل نباشد shorewall شروع به کار نمی‌کند.فرض کنید که شما می‌خواهید هیچ کس نتواند از شبکه‌ی اینترنت، فایروال را پینگ کند. در این زمان مانند شکل ‏3‑4عمل کنید.شکل ‏3‑4 نمایی از فایل policyشما می‌توانید برای تنظیم nat masquerade مانند شکل ‏3‑5 در فایلmasq عمل کنید.شکل ‏3‑5 فایل masqبرای تنظیمات دیگر می‌توانید با مراجعه به سایت shorewall از نمونه‌ها و syntaxهای ذکر شده استفاده کنید.تا این جا با تنظیمات shorewall آشنا شدیم حال نوبت به این می‌رسد که بررسی کنیم که چگونه فایل‌ها اجرا می شوند و چه دستوراتی در پشت صحنه اجرا می‌شود.زمانی که پیکر بندی‌های اولیه‌ را در shorewall انجام دادیم نوبت به start کردن آن می‌رسد. برای بررسی این که پشت صحنه جه اتفاقاتی می‌افتد می‌توان از همین قسمت کرد.نکته)زمانی که از فرمان shorewall start استفاده می‌کنید ممکن است با خطایی مواجه شوید این خطا ممکن است که به دلیل اشتباهات موجود در فایل‌های کانفیگ باشد که در این زمان باید به /var/log/shorwall-init.log مراجعه کنید تا این که متوجه علت خطا شویم و آن را بر طرف کنیمبرای شروع بررسی ابتدا مواردی که shorewall start نمایش داده می‌شود را بررسی می‌کنیم برنامه ‏3‑3 خروجی shorwall startرا نمایش می دهد.1 Compiling...2 Processing /etc/shorewall/params ...3 Processing /etc/shorewall/shorewall.conf...4 Loading Modules...5 Compiling /etc/shorewall/zones...6 Compiling /etc/shorewall/interfaces...7 Determining Hosts in Zones...8 Locating Action Files...9 Compiling /usr/share/shorewall/action.Drop for chain Drop...10 Compiling /usr/share/shorewall/action.Broadcast for chain Broadcast...11 Compiling /usr/share/shorewall/action.Invalid for chain Invalid...12 Compiling /usr/share/shorewall/action.NotSyn for chain NotSyn...13 Compiling /usr/share/shorewall/action.Reject for chain Reject...14 Compiling /etc/shorewall/policy...15 Running /etc/shorewall/initdone...16 Compiling Kernel Route Filtering...17 Compiling Martian Logging...18 Compiling /etc/shorewall/masq...19 Compiling MAC Filtration -- Phase 1...20 Compiling /etc/shorewall/rules...21 Compiling /usr/share/shorewall/action.Invalid for chain %Invalid...22 Compiling MAC Filtration -- Phase 2...23 Applying Policies...24 Generating Rule Matrix...25 Creating iptables-restore input...26 Shorewall configuration compiled to /var/lib/shorewall/.start27 Starting Shorewall....28 Initializing...29 Processing /etc/shorewall/init ...30 Processing /etc/shorewall/tcclear ...31 Setting up Route Filtering...32 Setting up Martian Logging...33 Setting up Proxy ARP...34 Setting up Traffic Control...35 Preparing iptables-restore input...36 Running /sbin/iptables-restore...37 Processing /etc/shorewall/start ...38 Processing /etc/shorewall/started ...39 done.برنامه ‏3‑3 خروجی shorwall startدر جدول ‏3‑1 به بررسی رخ داد‌ها در فاز شروع shorewall می‌پردازیم.جدول ‏3‑1 shorewall startupدر این قسمت با اتفاقاتی که در مرحله‌ی ابتدایی داد آشنا شدیم در قسمت بعدی با استفاده ازفرمان shorewall trace check –r به بررسی shorewall می‌پردازیم.خروجی فرمان shorewall trace check –r تعداد ۱۴۰۰ خط است که از آوردن تمام خطوط در این مستند خود داری می‌شود.برنامه ‏3‑4 خروجی فرمان shorewall trace ckeck –r است که نمایش میدهد چه environmentهایی اضافه و تغییر داده شده‌اند1 Checking...2 Processing /etc/shorewall/params ...3 Params:4 export DISPLAY='localhost:10.0'5 export HOME='/root'6 export LANG='en_US.UTF-8'7 export LANGUAGE='en_US:'8 export LESSCLOSE='/usr/bin/lesspipe %s %s'9 export LESSOPEN='| /usr/bin/lesspipe %s'10 export LOGNAME='root'11 export LS_COLORS='rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37; 44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;3 1:*.lz=01;31:*.xz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar= 01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35 :*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:* .mkv=01;35:*.webm=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc =01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.axv=01;35:*.anx=01;35:*.ogv=01;35: *.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.axa=00;36:*.oga =00;36:*.spx=00;36:*.xspf=00;36:'12 export MAIL='/var/mail/root'13 export PATH='/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin'14 export PWD='/root'15 export SHELL='/bin/bash'16 export SHLVL='1'17 export SSH_CLIENT='172.30.120.97 1853 30000'18 export SSH_CONNECTION='172.30.120.97 1853 172.30.120.110 30000'19 export SSH_TTY='/dev/pts/0'20 export TERM='xterm'21 export USER='root'22 export XDG_SESSION_COOKIE='601f24b9e443f2476b290a730000016b-1477977737.426237-1167493392'23 export _='/sbin/shorewallبرنامه ‏3‑4 خروجی فرمان Check در shorewallخروجی فرمان shorewall trace ckeck –r دارای قسمت‌های مختلفی است که می‌توان کانفیگ‌های خود shorewall را هم با استفاده از این فرمان مشاهده کرد.پیکربندی‌های shorewall را نمایش می‌دهد که قسمتی از آن را در اینجا آورده شده است.پیکربندی‌های shorewall در مسیر /etc/shorewall/shorewall.confاست.Processing /etc/shorewall/shorewall.conf...IN===> STARTUP_ENABLED=YesIN===> VERBOSITY=1IN===> BLACKLIST_LOGLEVEL=IN===> LOG_MARTIANS=YesIN===> LOG_VERBOSITY=2IN===> LOGALLNEW=IN===> LOGFILE=/var/log/messagesIN===> LOGFORMAT="Shorewall:%s:%s:"IN===> LOGTAGONLY=NoIN===> LOGLIMIT=IN===> MACLIST_LOG_LEVEL=infoIN===> SFILTER_LOG_LEVEL=infoIN===> SMURF_LOG_LEVEL=infoIN===> STARTUP_LOG=/var/log/shorewall-init.logIN===> TCP_FLAGS_LOG_LEVEL=infoIN===> CONFIG_PATH="/etc/shorewall:/usr/share/shorewall"IN===> IPTABLES=IN===> IP=IN===> IPSET=IN===> MODULESDIR=IN===> PATH="/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin"IN===> PERL=/usr/bin/perlIN===> RESTOREFILE=restoreIN===> SHOREWALL_SHELL=/bin/shIN===> SUBSYSLOCK=""IN===> TC=IN===> ACCEPT_DEFAULT=noneIN===> DROP_DEFAULT=DropIN===> NFQUEUE_DEFAULT=noneIN===> QUEUE_DEFAULT=noneIN===> REJECT_DEFAULT=RejectIN===> RCP_COMMAND='scp ${files} ${root}@${system}:${destination}'IN===> RSH_COMMAND='ssh ${root}@${system} ${command}'IN===> ACCOUNTING=YesIN===> ACCOUNTING_TABLE=filterIN===> ADD_IP_ALIASES=NoIN===> ADD_SNAT_ALIASES=NoIN===> ADMINISABSENTMINDED=YesIN===> AUTO_COMMENT=YesIN===> AUTOMAKE=NoIN===> BLACKLISTNEWONLY=YesIN===> CLAMPMSS=NoIN===> CLEAR_TC=YesIN===> COMPLETE=NoIN===> DELETE_THEN_ADD=Yesبرنامه ‏3‑5 پیکربندی shorewallبرنامه ‏3‑6 دستورات iptables اجرا شده را توسط shorewall نمایش می‌دهد1 SYS----> /sbin/iptables -N fooX70902 SYS----> /sbin/iptables -N foo1X70903 SYS----> /sbin/iptables -A fooX7090 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT4 SYS----> /sbin/iptables -A fooX7090 -p tcp -m multiport --dports 21,22 -j ACCEPT5 SYS----> /sbin/iptables -A fooX7090 -p tcp -m multiport --sports 60 -m multiport --dports 99 -j ACCEPT6 SYS----> /sbin/iptables -t nat -L -n7 SYS----> /sbin/iptables -t nat -N fooX70908 SYS----> /sbin/iptables -t nat -A fooX7090 -j SNAT --to-source 1.2.3.4 --persistent9 SYS----> /sbin/iptables -t nat -F fooX709010 SYS----> /sbin/iptables -t nat -X fooX709011 SYS----> /sbin/iptables -t mangle -L -n12 SYS----> /sbin/iptables -A fooX7090 -m conntrack --ctorigdst 192.168.1.1 -j ACCEPT13 SYS----> /sbin/iptables -A fooX7090 -m conntrack -p tcp --ctorigdstport 22 -j ACCEPT14 SYS----> /sbin/iptables -A fooX7090 -m conntrack ! --ctorigdst 1.2.3.415 SYS----> /sbin/iptables -A fooX7090 -p tcp -m multiport --dports 21,22 -j ACCEPT16 SYS----> /sbin/iptables -A fooX7090 -p tcp -m multiport --dports 21:22 -j ACCEPT17 SYS----> /sbin/iptables -A fooX7090 -m policy --pol ipsec --mode tunnel --dir in -j ACCEPT18 SYS----> /sbin/iptables -A fooX7090 -m physdev --physdev-in eth0 -j ACCEPT19 SYS----> /sbin/iptables -A fooX7090 -m physdev --physdev-is-bridged --physdev-in eth0 --physdev-out eth1 -j ACCEPT20 SYS----> /sbin/iptables -A fooX7090 -m iprange --src-range 192.168.1.5-192.168.1.124 -j ACCEPT21 SYS----> /sbin/iptables -A fooX7090 -m recent --update -j ACCEPT22 SYS----> /sbin/iptables -A fooX7090 -m owner --uid-owner 0 -j ACCEPT23 SYS----> /sbin/iptables -A fooX7090 -m connmark --mark 2 -j ACCEPT24 SYS----> /sbin/iptables -A fooX7090 -m connmark --mark 2/0xFF -j ACCEPT25 SYS----> /sbin/iptables -A fooX7090 -p tcp -m ipp2p --edk -j ACCEPT26 iptables v1.4.12: Couldn't load match `ipp2p':No such file or directory27 Try `iptables -h' or 'iptables --help' for more information.28 SYS----> /sbin/iptables -A fooX7090 -m length --length 10:20 -j ACCEPT29 SYS----> /sbin/iptables -A fooX7090 -j REJECT --reject-with icmp-host-prohibited30 SYS----> /sbin/iptables -A fooX7090 -j ACCEPT -m comment --comment "This is a comment"31 SYS----> /sbin/iptables -A fooX7090 -m hashlimit --hashlimit 3/min --hashlimit-burst 3 --hashlimit-name fooX7090 --hashlimit-mode srcip -j ACCEPT32 SYS----> /sbin/iptables -A fooX7090 -m hashlimit --hashlimit-upto 3/min --hashlimit-burst 3 --hashlimit-name fooX7090 --hashlimit-mode srcip -j ACCEPT33 SYS----> /sbin/iptables -t mangle -A fooX7090 -j MARK --set-mark 134 SYS----> /sbin/iptables -t mangle -A fooX7090 -j MARK --and-mark 0xFF35 SYS----> /sbin/iptables -t mangle -A fooX7090 -j MARK --set-mark 1/0xFF36 SYS----> /sbin/iptables -t mangle -A fooX7090 -j CONNMARK --save-mark37 SYS----> /sbin/iptables -t mangle -A fooX7090 -j CONNMARK --save-mark --mask 0xFF38 SYS----> /sbin/iptables -t mangle -A fooX7090 -j CLASSIFY --set-class 1:139 SYS----> /sbin/iptables -t mangle -A fooX7090 -j IPMARK --addr src40 iptables v1.4.12: unknown option "--addr"41 Try `iptables -h' or 'iptables --help' for more information.42 SYS----> /sbin/iptables -t mangle -A fooX7090 -p tcp -j TPROXY --on-port 0 --tproxy-mark 143 SYS----> /sbin/iptables -t mangle -F fooX709044 SYS----> /sbin/iptables -t mangle -X fooX709045 SYS----> /sbin/iptables -t mangle -L FORWARD -n46 SYS----> /sbin/iptables -t raw -L -n47 SYS----> /sbin/iptables -t rawpost -L -n 48 iptables v1.4.12: can't initialize iptables table `rawpost': Table does not exist (do you need to insmod?)49 Perhaps iptables or your kernel needs to be upgraded.50 SYS----> /sbin/iptables -A fooX7090 -m pkttype --pkt-type broadcast -j ACCEPT51 SYS----> /sbin/iptables -A fooX7090 -m addrtype --src-type BROADCAST -j ACCEPT52 SYS----> /sbin/iptables -A fooX7090 -p tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1000:1500 -j ACCEPT53 SYS----> /sbin/iptables -A fooX7090 -j NFQUEUE --queue-num 454 SYS----> /sbin/iptables -A fooX7090 -m realm --realm 155 SYS----> /sbin/iptables -A fooX7090 -m helper --helper "ftp"56 SYS----> /sbin/iptables -A fooX7090 -m connlimit --connlimit-above 857 SYS----> /sbin/iptables -A fooX7090 -m time --timestart 11:0058 SYS----> /sbin/iptables -A fooX7090 -g foo1X709059 SYS----> /sbin/iptables -A fooX7090 -j LOG60 SYS----> /sbin/iptables -A fooX7090 -j ULOG61 SYS----> /sbin/iptables -A fooX7090 -j NFLOG62 SYS----> /sbin/iptables -A fooX7090 -j LOGMARK63 iptables v1.4.12: Couldn't load target `LOGMARK':No such file or directory64 Try `iptables -h' or 'iptables --help' for more information.65 SYS----> /sbin/iptables -A fooX7090 -j MARK --set-mark 566 SYS----> /sbin/iptables -A fooX7090 -j ACCOUNT --addr 192.168.1.0/29 --tname fooX709067 iptables v1.4.12: unknown option "--addr"68 Try `iptables -h' or 'iptables --help' for more information.69 SYS----> /sbin/iptables -A fooX7090 -j AUDIT --type drop70 SYS----> /sbin/iptables -A fooX7090 -m condition --condition foo71 iptables v1.4.12: Couldn't load match `condition':No such file or directory72 Try `iptables -h' or 'iptables --help' for more information.73 SYS----> /sbin/iptables -S INPUT74 SYS----> /sbin/iptables -F fooX709075 SYS----> /sbin/iptables -X fooX709076 SYS----> /sbin/iptables -F foo1X709077 SYS----> /sbin/iptables -X foo1X7090برنامه ‏3‑6 دستورات iptablesبرای بررسی deamen در shorewall به همین موارد اکتفا می‌کنیم به بررسی نمودارهای اجرایی آن می‌پردازیمدر شکل ‏3‑5 مشاهده می‌کنید که نرم‌افزار shorewall در صورت تغییر وضعیت در چه حالت‌هایی وارد می‌شود.شکل ‏3‑7 ‌state diagram shorewallدر فوچارت نمایش داده شده در شکل ‏3‑6 می‌توان روند کاری درshorewall را مشاهده کردشکل ‏3‑6 فلوچارت اجرای shorewallدر این قسمت بررسی shorewall به پایان رسید در صورت نیاز به بررسی‌های بیشتر می‌توان به manualآن مراجعه کرد و یا این که به سایت رفت ونیاز‌های خود را استخراج کرد.3-3 آموزش UFWابزار ufw به صورت پیش‌فرض برای لینوکس انتخاب شده و بر روی آن نصب شده است. این ابزار این امکان را فراهم می‌آورند تا بتوان راحتر از قابلیت‌های iptablesاستفاده کرد. در این قسمت به بررسی دقیق این ابزار می‌پردازیم و این که با چندین مثال و نمونه با این ابزار آشنا می‌شویم.برای استفاده از UFW می‌توان به دوصورت عمل کرد:1. اعمال تنظیمات توسط فرمان ufw2. اعمال تنظیمات با استفاده از تغییرات در فایل پیکربندی مربوط به UFWدر ابتدا به اعمال تنظیمات توسط فرمان UFW می‌پردازیم.3-4 فرمان UFWزمانی که برای اولین بار فرمان UFW را فعال می‌شود مجموعه‌ای از قوانین که به صورت پیش‌فرض تعیین شده‌اند اجرا می‌شوند. و ما می‌توانیم این قوانین را تغییر دهیم اما در این قسمت به آن پرداخته نمی‌شود و در این قسمت فقط به نحوه‌ی استفاده از UFWپرداخته می‌شود.برای فعال کردن UFW از برنامه ‏3‑8 استفاده می‌شود.Sudo ufw enableبرنامه ‏3‑8 enable commandبرای بررسی وضعیت UFW از برنامه ‏3‑9 استفاده می‌شودsudo ufw status verboseبرنامه ‏3‑9 status commandتوجه کنید که باenable کردن UFW، فایروال به deny کردن برخی از ورودی‌ها می‌پردازد که شما می‌توانید استثناها را با وارد کردن دستور برنامه ‏3‑10 مشاهده کنیدSudo ufw status verboseبرنامه ‏3‑10 status commandبرای غیر فعال کردن UFW از برنامه ‏3‑11 استفاده می‌کنیمSudo ufw desableبرنامه ‏3‑11 disable3-4-1 نحوه‌یAllow و denyبرای این که یک قانونی را Allow کنیم مانند برنامه ‏3‑12 عمل می‌کنیمsudo ufw allow /برنامه ‏3‑12 port and IPبرای درک بهتر چندین مثال و نمونه در ادامه آورده شده است.فرمانی که اجازه‌ی ورود و خروج را برای پروتکل‌های tcpو udp بر روی پورت 53 می‌دهد برنامه ‏3‑13sudo ufw allow 53برنامه ‏3‑13 port allowفرمانی که اجازه‌ی ورود و خروج را برای پروتکل‌های tcpبر روی پورت 53 می‌دهد برنامه ‏3‑14sudo ufw allow 53/tcpبرنامه ‏3‑14 port allowفرمانی که اجازه‌ی ورود و خروج را برای پروتکل‌هایudpبر روی پورت 53 می‌دهد برنامه ‏3‑15sudo ufw allow 53/udpبرنامه ‏3‑15 allow portفرمانی که به deny کردن برخی بسته‌های شبکه‌ و یا ترافیک می‌پردازد مانند برنامه ‏3‑16 استsudo ufw allow /برنامه ‏3‑16 allow port and protocolفرمانی که پروتکل‌های udp و tcp را بر روی پورت ۵۳ می‌بندد. برنامه ‏3‑17sudo ufw deny 53برنامه ‏3‑17 deny portفرمانی که پروتکل tcp را که به صورت ورودی هستند را بر روی پورت ۵۳ می‌بندد. برنامه ‏3‑18sudo ufw deny 53/tcpبرنامه ‏3‑18 dny port and protocolفرمانی که پروتکل udp را که به صورت ورودی هستند را بر روی پورت ۵۳ می‌بندد. برنامه ‏3‑19sudo ufw deny 53/udpبرنامه ‏3‑19 deny port and protocol3-4-2 حذف یک قانونفرض کنید که یک فرمان مانند برنامه ‏3‑20 را وارد کرده‌اید و می‌خواهید آن را حذف کنید.ufw deny 80/tcpبرنامه ‏3‑20 deny port and protocolبرای حذف این فرمان می‌توانید از برنامه ‏3‑21 استفاده کنیدsudo ufw delete deny 80/tcpبرنامه ‏3‑21 delete rule3-4-3 سرویس‌هابرای allow کردن یک سرویس مانند برنامه ‏3‑22 عمل می‌کنیمsudo ufw allow برنامه ‏3‑22 allow or deny serviceفرض کنید که می‌خواهید سرویسی را مانند ssh را که بر روی سیستم deny شده را allow کنید از برنامه ‏3‑23 برای انجام این کار استفاده می‌کنیم.sudo ufw allow sshبرنامه ‏3‑23 ssh enable3-4-4 مشاهده‌ی وضعیتبرای مشاهده‌ی وضعیت می‌توانید از دستور برنامه ‏3‑24 استفاده کنیدsudo ufw statusبرنامه ‏3‑24 statusبرنامه ‏3‑24 وضعیت قوانینی که با Iptables اعمال شده را نمایش می دهد که خروجی آن مانند برنامه ‏3‑25 استFirewall loadedTo Action From-- ------ ----22:tcp DENY 192.168.0.122:udp DENY 192.168.0.122:tcp DENY 192.168.0.722:udp DENY 192.168.0.722:tcp ALLOW 192.168.0.0/2422:udp ALLOW 192.168.0.0/24برنامه ‏3‑25 rule list3-4-5 اعمال قوانین پیشرفتهبرای اعمال قوانین پیشرفته با استفاده از ufw چندین مثال را دنبال می‌کنیم.برای allow کردن یک ip خاص مانند برنامه ‏3‑26 استفاده می‌کنیم.sudo ufw allow from برنامه ‏3‑26 sowcific IPبه عنوان مثال تمام بسته‌ها از سمت 172.30.120.12اجازه‌ی ورود را داشته باشند برنامه ‏3‑27sudo ufw allow from 172.30.120.12برنامه ‏3‑27 specific IPدر صورتی که قصد داشتیم اجازه‌ی ورود برای بسته‌های یک subnetخاص مانند 172.30.120.0/24صادر کنیم می‌توانیم از برنامه ‏3‑28 استفاده کنیمsudo ufw allow from 172.30.120.0/24برنامه ‏3‑28 allow fromدر صورتی که قصد داشتیم یک ip و یا پورت خاص را aloow یا deny کنیم مانند برنامه ‏3‑29 عمل می‌کنیمsudo ufw allow from to port برنامه ‏3‑29 ip , portبه عنوان نمونه قصد داریم تمامی پروتکل‌ها از ip 192.168.1.5 با پورت 22 اجازه‌ی ورود را داشته باشند برنامه ‏3‑30sudo ufw allow from 192.168.1.5 to any port 22برنامه ‏3‑30 ip , portبرای مشخص کردن این که یک ip خواص با یک پورت و پروتکل خواص می‌تواند وارد شود مانند برنامه ‏3‑31 عمل می‌کنیم.sudo ufw allow from to port proto برنامه ‏3‑31ip , port , protocolبه عنوان نمونه ip 192.168.1.5 همراه با پورت 22 و پروتکل tcp اجازه‌ی ورود را دارد. برنامه ‏3‑32sudo ufw allow from 192.168.0.4 to any port 22 proto tcpبرنامه ‏3‑32 ip , port , protocolنکته) در صورتی که در فرمان‌های گفته شده به جای کلمه‌ی allow از deny استفاده کنید نتیجه‌ی کار deny خواهد شد.برای فعال کردن یا غیر فعال کردن ping باید فایل etc/ufw/before.rules را تغییر دهید.زمانی که وارد /etc/ufw/before.rules می‌شوید تمامی خطوط زیر را (برنامه ‏3‑33 ) پیدا کرده و پاک کنید.# ok icmp codes-A ufw-before-input -p icmp --icmp-type destination-unreachable -j ACCEPT-A ufw-before-input -p icmp --icmp-type source-quench -j ACCEPT-A ufw-before-input -p icmp --icmp-type time-exceeded -j ACCEPT-A ufw-before-input -p icmp --icmp-type parameter-problem -j ACCEPT-A ufw-before-input -p icmp --icmp-type echo-request -j ACCEPTبرنامه ‏3‑33 ping dropو یا این که ACCEPT را به DROP تغییر دهید. برنامه ‏3‑34# ok icmp codes-A ufw-before-input -p icmp --icmp-type destination-unreachable -j DROP-A ufw-before-input -p icmp --icmp-type source-quench -j DROP-A ufw-before-input -p icmp --icmp-type time-exceeded -j DROP-A ufw-before-input -p icmp --icmp-type parameter-problem -j DROP-A ufw-before-input -p icmp --icmp-type echo-request -j DROPبرنامه ‏3‑34 ping drop3-4-6 نحوه‌ی NAT با UFWبرای NAT کردن با استفاده از UFW باید که در ابتدا وارد /etc/default شده و خط DEFAULT_FORWARD_POLICY را به DEFAULT_FORWARD_POLICY="ACCEPT”تغییر دهیم.همان گونه که می‌دانیم سرویس‌ها پارامتر‌های مورد نیاز خورد را در /etc/default قرار می‌دهند تا در زمان قبل از start اعمال شوند.در مرحله‌ی بعد برای NAT کردن باید IP_FORWARD بر روی سیستم فعال کنیم برای این کار وارد /etc/ufw/sysctl.conf شده و مقدار ip_forward را برابر یک می‌کنیم. برنامه ‏3‑35net.ipv4.ip_forward=1#net/ipv6/conf/default/forwarding=1#net/ipv6/conf/all/forwarding=1برنامه ‏3‑35 enable ip_forwardingدر مرحله‌ بعد نوبت به اعمال NAT می‌رسد. برای این کار را به انتهای فایل /etc/ufw/before.rulesقبل از filter ruleاستفاده می‌شود. برنامه ‏3‑36# NAT table rules*nat:POSTROUTING ACCEPT [0:0]# Forward traffic through eth0 - Change to match you out-interface-A POSTROUTING -s 192.168.1.0/24 -o eth0 -j MASQUERADE# don't delete the 'COMMIT' line or these nat table rules won't# be processedCOMMITبرنامه ‏3‑36 natبا اعمال آدرس‌های 192.168.1.0/24 به ip اینترفیس eth0 ترجمه می‌شوند.در انتها برای اعمال تغییرات فرمان برنامه ‏3‑37 را اجرا کنیدsudo ufw disable && sudo ufw enableبرنامه ‏3‑37 راه اندازی مجدد3-4-7 بررسی دقیق تر UFWخود Ufw دو امکان command lineو یک framework را فراهم آورده تا این که بتوان netfilter را مدیریت کرد. در حالی که ufw framework یک روشی را برای مدیریت و شخصی سازی رفتار‌های پیش فرض فراهم می‌آورد.چارچوب یا Frameworkمواردی را شامل مقدار اولیه دهی در زمان boot، وجود rules file برای افزودن یک rule جدید، روشی برای load کردن moduleهای مورد نیاز یا پیکربندی پارامتر‌های کرنل و ipv6 شامل می‌شود که این‌ها عبارتند از:/lib/ufw/ufw-initاسکریپت مقدار دهی اولیه /etc/ufw/before[6].rules4 مراجع“List of router and firewall distributions,” Wikipedia. 19-Oct-2016.[2] “1.1. Partial List of Features.” [Online]. Available: http://www.ipcop.org/2.0.0/en/install/html/features.html. [Accessed: 22-Oct-2016].[3] “pfSense,” Wikipedia. 15-Oct-2016.[4] “Express Feature List.” [Online]. Available: http://www.smoothwall.org/about/express-feature-list/. [Accessed: 22-Oct-2016].[5] “Open Source Firewall Features | Endian Firewall Community,” Securing everyThing: Firewall, UTM, Hotspot, VPN, IoT. .[6] “ClearOS,” Wikipedia. 14-Oct-2016.[7] “m0n0wall - Features.” [Online]. Available: http://m0n0.ch/wall/features.php. [Accessed: 22-Oct-2016].[8] “www.ipfire.org - About IPFire.” [Online]. Available: http://www.ipfire.org/features. [Accessed: 22-Oct-2016].[9] “Alpine Linux,” Wikipedia. 11-Oct-2016.[10] “LibreSSL,” Wikipedia. 17-Oct-2016.[11] “OPNsense firewall features.” [Online]. Available: https://docs.opnsense.org/. [Accessed: 25-Oct-2016].[12] “Devil Linux - Features.” [Online]. Available: http://www.devil-linux.org/product/features.php. [Accessed: 25-Oct-2016].[13] “Untangle Documentation.” [Online]. Available: https://wiki.untangle.com/index.php/Main_Page. [Accessed: 25-Oct-2016].[14] “Feature list - VyOS.” [Online]. Available: http://wiki.vyos.net/wiki/Feature_list. [Accessed: 25-Oct-2016].[15] “iptables-extensions.” [Online]. Available: http://ipset.netfilter.org/iptables-extensions.man.html. [Accessed: 30-Oct-2016].برای تماس با بنده می‌توانید از لینک زیر استفده کنید https://teaching.iranmodares.com/teaching-index.php?metaword=%D9%85%D8%AD%D9%85%D8%AF+%D8%AD%D8%B3%DB%8C%D9%86+%D8%AC%D9%84%DB%8C%D9%84%DB%8C

مدیریت متمرکز پیکربندی با استفاده از SALT

محمد حسین جلیلی — Fri, 18 Nov 2022 01:01:17 +0330
آموزش SALT1 مدیریت پیکربندی1-1 مقدمهابزار salt یک راهکار جدید در مدیریت زیرساخت با قابلیت‌هایی همچون نصب و راه‌اندازی آسان، با قابلیت گسترش‌پذیری سریع و آسان ایجاد کرده است. این ابزار با فراهم آوردن یک ارتباط پویا و مستقل از دیگر سرویس‌ها امکان هماهنگی، اجرای دستورات از راه دور و مدیریت پیکربندی را فراهم می‌آورد.به دلیل تنوع محصولات و فعالیت‌های پوشش داده شده، در ابزار Salt تلاش‌گردیده است تا اکثر امکانات به‌منظور قابل‌گسترش بودن، به‌صورت پیمانه‌ای پیاده‌سازی شده است. به‌طورمعمول تنها پیمانه‌های اجرایی و وضعیت موردتوجه‌ قرار می‌گیرند. بااین‌وجود قالب بخش‌های Salt به‌صورت پیمانه‌ای توسعه یافته است که در ادامه به برخی از آن‌ها خواهیم پرداخت.1-2 ساختار کلیدر شکل ‏2‑1معماری ارتباط masterبا minionها در ابزار saltمشاهده می‌شود.شکل ‏2‑1معماری ارتباط master با minionهادر ادامه‌ی این بخش در مثال‌ها از ساختاری مشابه شکل ‏2‑1 استفاده خواهد شد که در آن پنج minion به نام‌های ubuntu-200-199 ، ubuntu-220-235، ubuntu-220-249 ، ubuntu-221-22 و ubuntu-221-55 به ماشین master با نام ubunut-221-0 متصل شده است.1-2-1 راهکار‌های ارتباط در سامانهدر معماری برنامه‌های توزیع‌شده که در آن‌ها اجزای برنامه بر روی چندین میزبان چندین هسته‌ی پردازشی از طریق اینترنت به یکدیگر متصل‌ هستند، به‌طورمعمول ارتباط میان اجزا از طریق گذرگاه رخداد و یا پیام‌رسانی برقرار می‌شود.بهره‌گیری از این راهکارها امکان ارتباط نامتقارن با یکدیگر را فراهم می‌آورد. این راهکار‌ها به‌طورمعمول از مدل انتشار/اشتراک برای تبادل اطلاعات بهره می‌گیرند. در معماری ابزار Salt دو راهکار زیر را برای ارتباط پیشنهاد می‌کند.1-2-1-1 راهکارZeroMQبا وجود مزایای متعدد روش‌ها صف‌بندی پیام، یکی از معایب این روش‌ها عدم گسترش‌پذیری برای ابزار‌هایی نظیر Salt است.1-2-1-2 راهکار RAETراهکاری مطمئن با سربار بسیار کمتر از ZeroMQ که از پروتکل UDP استفاده می‌کند و برای ابزار salt در حال توسعه است.1-2-2 امنیت در ارتباطبرای ایجاد اتصال و امنیت در ارتباط، در ابزار salt از مکانیسم کلید عمومی برای ارتباط اولیه با master و رمزنگاری مقارن AES با طول کلید 256 بیت برای رمزنگاری داده‌های ارتباط استفاده می‌شود.1-2-3 بهره‌گیری از قالب برای انعطاف در پیکربندیهر قابلیتی در این ابزار به‌صورت فایل نمایش داده می‌شود. برای سادگی نمایش و خوانایی آن‌ها از زبان نشانه‌گذاری YAML استفاده است. این زبان علی‌رغم سادگی و خوانایی، قابلیت توسعه و گسترش‌پذیری ابزار را افزایش می‌دهد.همچنین ابزار Salt از موتور ایجاد قالب Jinja2 در پایتون بهره می‌برد. این ابزار که به‌صورت کامل از Unicode پشتیبانی می‌کند، با الهام از ساختار قالب در سامانه‌ی Django نوشته شده و قابلیت‌های فراوانی را به توسعه‌دهنده می‌دهد. یکی دیگر از قابلیت‌های بسیار مهم در این موتور، اجرا و تولید قالب به‌صورت ایزوله شده و درون ساعت شنی، همراه با قابلیت نادیده‌گیری مواردی برای برنامه‌های کاربردی در مواردی که امنیت از اهمیت بالای برخوردار است، اشاره کرد.ازجمله ویژگی‌های مهم Jinja2 می‌توان به موارد زیر اشاره کرد:اجرای فرمان‌ها در حالت ساعت شنینادیده‌گیری خودکار HTMLبرای جلوگیری از حملات XSSقابلیت ارث‌بری در قالب‌ها برای کاهش تکرار و اشتباه در ایجاد قالبکارایی بالا در ساخت و تفسیر قالب‌هاساختار نحوی قابل پیکربندی.1-3 راهنمای نصبراهکار نصب ابزار salt در توزیع‌های مختلف متفاوت است ولی ازآنجایی‌که نصب و توسعه‌ی آسان یکی از اهداف این ابزار است، در اکثر توزیع‌ها تنها با چند دستور قابل نصب و راه‌اندازی است. بااین‌وجود در توزیع‌های Ubuntu و debian دستورات پیش‌نیازی وجود دارد که در قطعه برنامه ‏2‑1 و قطعه برنامه ‏2‑2 آورده شده است. این دستورات تنها برای افزودن مخازن موردنیاز به سامانه‌ هستند.$ sudo apt-get install python-software-properties software-properties-common$ sudo add-apt-repository ppa:saltstack/salt$ sudo apt-get updateقطعه برنامه ‏2‑1دستورات پیش‌نیاز برای نصب salt در ubuntu$ sudo echo "deb http://debian.saltstack.com/debian wheezy-saltstack main" >> /etc/apt/sources.list.d/salt.rep$ wget -q -O- "http://debian.saltstack.com/debian-salt-team-joehealy.gpg.key" | apt-key add –$ apt-get updateقطعه برنامه ‏2‑2 دستورات پیش‌نیاز برای نصب salt در debianعلاوه بر راهکار‌های ارائه شده برای نصب هر یک از اجزا به‌صورت جدا‌گانه، ازآنجایی‌که این ابزار بر روی PyPi قرار دارد، می‌توان مطابق قطعه برنامه ‏2‑3 ابزار masterرا بر روی هر توزیع نصب کرد.pip install saltقطعه برنامه ‏2‑3 نصب کلیه‌ی ابزار‌ها با استفاده از pip1-3-1 نصب و پیکربندی اولیه masterهمان‌طور که در بخش ‏2-2 بیان شد، سامانه‌ای که نقش مدیریت دیگر سامانه‌ها را بر عهده دارد، master نامیده می‌شود. درصورتی‌که از قطعه برنامه ‏2‑3 استفاده نشده باشد، می‌توان برای نصب و راه‌اندازی این بخش از سامانه، بر روی ماشین موردنظر با توجه به توزیع ماشین از هر یک از قطعه برنامه ‏2‑4 و قطعه برنامه ‏2‑5 بهره برد.$ sudo apt-get install salt-master$ sudo service salt-master startقطعه برنامه ‏2‑4 نصب master بر روی توزیع‌های ubuntu و debian$sudo yum install salt-master$sudo systemctl enable salt-master.serviceقطعه برنامه ‏2‑5 نصب master بر روی توزیع‌ fedoraپس از نصب این بخش، فایل پیکربندی در آدرس /etc/salt/masterقرار خواهد گرفت که در بخش‌های بعدازآن بهره خواهیم جست. در این فایل آدرس دسترسی به شبکه به‌صورت پیکربندی ‏2‑1 اضافه گردد و سرویس salt-master راه‌اندازی مجدد گردد.interface: 10.0.0.1پیکربندی ‏2‑1تعیین آدرس در فایل پیکربندی master1-3-2 نصب و پیکربندی اولیه minionهمان‌طور که در بخش ‏2-2 بیان شد، سامانه‌ای که در سامانه به‌وسیله‌ی master مدیریت می‌شود دیگر سامانه‌ها را بر عهده دارد، minion نامیده می‌شود. درصورتی‌که از قطعه برنامه ‏2‑3 استفاده نشده باشد، می‌توان برای نصب و راه‌اندازی این بخش از سامانه، بر روی ماشین موردنظر با توجه به توزیع ماشین از هر یک از قطعه برنامه ‏2‑6 و قطعه برنامه ‏2‑7 بهره برد.$ sudo apt-get install salt-master$ sudo service salt-master startقطعه برنامه ‏2‑6 نصب minion بر روی توزیع‌های ubuntu و debian$sudo yum install salt-master$sudo systemctl enable salt-master.serviceقطعه برنامه ‏2‑7 نصب minion بر روی توزیع‌ fedoraپس از نصب این بخش، فایل پیکربندی در آدرس /etc/salt/minion قرار خواهد گرفت که در بخش‌های بعدازآن بهره خواهیم جست. در این فایل در صورت تمایل به اتصال به masterباید آدرس را به‌صورت پیکربندی ‏2‑2 به فایل پیکربندی اضافه و سرویس را راه‌اندازی مجدد کرد.master: 10.0.0.1پیکربندی ‏2‑2تعیین آدرس master در فایل پیکربندی minionبا اجرای minion اسمی برای ماشین جاری ایجاد می‌شود که در فایل /etc/salt/minion_id قرار می‌گیرد. از این اسم برای احراز هویت در master استفاده می‌شود. برای تعیین اسم ماشین، موارد زیر به ترتیب انجام می‌شود:1- فراخوانی تابع socket.getfqdn() در python2- بررسی محتوای فایل /etc/hostname در ماشین‌های که سیستم‌عامل آن‌ها windows نیست.3- بررسی فایل /etc/hosts و چک کردن هر مقداری که با آدرس 127.0.0.0/8 متناظر است.1-3-3 پذیرش اتصال minion ها به masterهمان‌طور که در ‏2-2-2 بیان شد، ارتباط بین master و minion از طریق رمزنگاری امن می‌گردد. برای جلوگیری از ایجاد ارتباط‌های ناخواسته، پس از اتصال minion به master باید آن minion در master احراز هویت گردد. برای پذیرش یک minion از طریق قطعه برنامه ‏2‑8 عمل می‌کنیم.$ salt-key –a MINION-NAMEقطعه برنامه ‏2‑8پذیرش یک اتصال در masterهمچنین می‌توان کلید تمام minionها را به صورت همزمان با قطعه برنامه ‏2‑9 پذیرفت.$ salt-key -Aقطعه برنامه ‏2‑9 پذیرش تمام کلید‌ها در masterبرای عدم پذیرش یک minion باید از قطعه برنامه ‏2‑10 استفاده کرد.$ salt-key -r MINION-NAMEقطعه برنامه ‏2‑10 عدم پذیرش یک اتصال در masterبرای مشاهده‌ی وضعیت تمام اتصالات می‌توان از قطعه برنامه ‏2‑11 استفاده کرد.$ salt-key -Lقطعه برنامه ‏2‑11مشاهده‌ی لیست وضعیت تمام اتصالات در masterبه عنوان مثال در شکل ‏2‑2مراحل مشاهده‌ی وضعیت اتصال minonها و پذیرش تمام کلید‌ها نشان داده شده است. در این شکل ابتدا با دستور salt-key –Lتمام کلید‌هایی که هنوز پذیرفته نشده اند مشاهده می‌شود. در ادامه با دستور salt-key –A تمام کلید‌ها پذیرفته می‌شوند که نتیجه‌ی آن را می‌توان با تغییر وضعیت نام minionها به حالت پذیرفته شده مشاهده کرد.شکل ‏2‑2 مراحل پذیرش تمام کلید‌ها در master1-4 انتخاب minion برای اجرای فرمانهمان‌طور که گفته‌شده هر master می‌تواند چندین minion را مدیریت کند. برای مشخص کردن ماشینی که قرار است فرمان‌ها بر روی آن اجرا شود می‌توان از روش‌های مختلفی استفاده کرد که در ادامه به آن‌ها خواهیم پرداخت.1-4-1 نام Minionهر minion با نام مشخصی در master ثبت‌نام می‌کند. برای اجرای دستورات می‌توان با استفاده از نام minionها به آن‌ها فرمان‌هایی را صادر کرد. در ادامه دستور test.ping را که تنها وجود ارتباط بین master و minion را با برگرداندن مقدار true به ازای هر فراخوانی مشخص می‌کند و ارتباطی با دستور سیستمی ping ندارد را بر روی مثال ‏2-2 نمایش خواهیم داد.با استفاده از قطعه برنامه ‏2‑12 می‌توان دستور test.ping را تنها بر روی ماشین ubuntu-220-199 اجرا کرد. در شکل ‏2‑3 نیز نتیجه‌ی اجرای این دستور قابل مشاهده است.$ salt 'ubuntu-220-199' test.pingقطعه برنامه ‏2‑12اجرای دستور Pingبر روی ماشین ubuntu-220-199شکل ‏2‑3 اجرای دستور تنها بر روی یک minionهمچنین می‌توان با استفاده از عبارات منظم دستورات را بر روی چندین دستگاه مختلف اجرا کرد. به عنوان مثال با استفاده از قطعه برنامه ‏2‑13 دستور test.ping بر روی ماشین‌هایی که در نام آنها‌ 220و 221 وجود دارد، اجرا می‌شود. در شکل ‏2‑4 نتیجه‌ی اجرای قطعه برنامه ‏2‑13 آورده شده است.$ salt '*220*' test.ping$ salt '*221*' test.pingقطعه برنامه ‏2‑13اجرای دستور Ping بر روی ماشین‌هایی که در نام آنها‌ 220و 221 وجود داردشکل ‏2‑4اجرای دستور Ping بر روی ماشین‌هایی که در نام آنها‌ 220 و 221 وجود داردبا استفاده از قطعه برنامه ‏2‑14بر روی تمام ماشین‌ها دستور ping را اجرا می‌شود که نتیجه‌ی آن را در شکل ‏2‑5 آورده شده است.$ salt '*' test.pingقطعه برنامه ‏2‑14اجرای دستور Ping بر روی تمام ماشین‌هاشکل ‏2‑5 اجرای دستور pingبر روی تمام ماشین‌ها1-4-2 آدرسIP ماشینمی‌توان از طریق آدرس شبکه نیز ماشین‌های موردنظر را انتخاب کرد. به‌عنوان‌مثال در قطعه برنامه ‏2‑15 دستور pingتنها بر روی ماشین با آدرس 192.168.40.20 اجرا می‌شود.salt -S 192.168.40.20 test.pingقطعه برنامه ‏2‑15اجرای دستور ping بر روی ماشین با ip مشخصهمچنین می‌توان دستورات را بر روی زیر‌دامنه‌ای از شبکه اجرا کرد. به‌عنوان‌مثال در قطعه برنامه ‏2‑16 دستور pingبر روی زیر دامنه‌ی 10.0.0.0/24 اجرا می‌شود.salt -S 10.0.0.0/24 test.pingقطعه برنامه ‏2‑16 اجرای دستورات بر روی زیر دامنه‌1-4-3 مقادیر Grainمقادیر Grainها مشخصاتی هستند که minionها برای master ارسال می‌کنند. این مشخصات که شامل مشخصات سیستم‌عامل، مشخصات سخت‌افزاری هستند می‌توانند در انتخاب هدف دستور‌ها مورد استفاده قرار گیرند. به‌عنوان‌مثال با استفاده از قطعه برنامه ‏2‑17 می‌توان از حضور ماشین‌های با سیستم‌عامل centOS اطلاع یافت.salt -G 'os:CentOS' test.pingقطعه برنامه ‏2‑17 اجرای دستور بر روی سیستم‌عامل خاصهمچنین با استفاده از قطعه برنامه ‏2‑18 می‌توان تعداد پردازنده‌های ماشین‌های با معماری 64 بیتی را مشاهده کرد.salt -G 'cpuarch:x86_64' grains.item num_cpusقطعه برنامه ‏2‑18 اجرای دستور بر روی ماشین با معماری خاص1-4-4 مقادیر Pillarعلاوه بر اطلاعاتی که هر minion از بررسی مشخصات خود جمع‌آوری و به master انتقال ‌می‌دهد، salt بستری ایمن برای minionها فراهم آورده است تا هر minion اطلاعات منحصربه‌فرد خود را که نیازی به اشتراک‌گذاری آن‌ها نیست را نگه‌داری کند. به‌عبارت‌دیگر grainاطلاعاتی است که minionها از وضعیت خود جمع‌آوری می‌کنند و به master انتقال می‌دهند ولی pillar اطلاعاتی است که master به‌صورت محرمانه در مورد هر minion به‌صورت جداگانه نگه‌داری می‌کند. به همین دلیل اطلاعاتی نظیر نوع سیستم‌عامل و نوع سخت‌افزار در grain و مواردی همچون کلید‌های رمزنگاری در pillarنگه‌داری می‌شود. اطلاعات موجود در pillar نیز می‌تواند برای انتخاب هدف دستورات مورد استفاده قرار گیرد.1-4-5 گروهی از Minionابزار salt امکان گروه‌بندی minion ها را نیز در اختیار قرار می‌دهد. هر minion ممکن است در چند گروه مختلف حضور داشته باشد.1-4-6 اجرای دسته‌ایهمان‌طور که در بخش‌های گذشته بیان شد می‌توان در هر دستور تعدادی از ماشین‌ها را انتخاب کرد. حال اگر بخواهیم اجرای دستور به‌صورت دسته‌ای، هر بار، بر روی بخشی از این گروه اجرا شود، مطابق دستورات زیر عمل می‌کنیم.1-4-6-1 اجرای تعداد مشخصیهمان‌طور که گفته شد می‌توان بر روی تعداد مشخصی از هر مجموعه‌ی تعیین شده از ماشین‌ها دستورات را اجرا کرد. به‌عنوان‌مثال در قطعه برنامه ‏2‑19 دستور ping بر روی تمامی ماشین‌ها، هر بار به تعداد 10 تا و به‌صورت پشت سر هم اجرا می‌شود.$ salt '*' -b 10 test.pingقطعه برنامه ‏2‑19اجرای دستور ping هر بار بر روی 10 ماشین1-4-6-2 اجرای درصد مشخصیمی‌توان در اجرای فرمان‌ها، درصد مشخصی را برای هر دستور مشخص کرد. به‌عنوان‌مثال در قطعه برنامه ‏2‑20هر بار در 25% ماشین‌هایی که سیستم‌عامل آن‌ها Redhat است، سرویس apache سیگنال راه‌اندازی مجدد دریافت می‌کنند.$salt -G 'os:RedHat' --batch-size 25% apache.signal restartقطعه برنامه ‏2‑20 اجرای دستور بر روی 25% ماشین‌های با سیستم‌عامل RedHat1-5 سامانه‌ی سرویس‌دهنده‌ی فایلابزار salt برای توزیع فایل‌های در minion ها از یک سرویس‌دهنده‌ی فایل بهره می‌برد. سرویس‌دهنده‌ی فایل یک سرویس‌دهنده‌ی بدون حالت بر روی بستر ارتباطی ZeroMQ است که در master پیاده ‌شده است. هدف از این سرویس‌دهنده در دسترس قرار دادن فایلهای پیکربندی در سیستم وضعیت salt است؛ بااین‌وجود هر نوع فایلی از طریق این سامانه قابل‌توزیع است. این سامانه علاوه بر توانایی مدیریت فایل‌های حجیم، توانایی مدیریت کارآمد فایل‌های با حجم کم را نیز دارد.1-5-1 سرویس‌دهنده‌ی فایل به‌صورت محلیسامانه‌ی سرویس‌دهنده‌ی فایل با آگاهی از متغیر‌های محیطی قادر به تخصیص مسیر‌های مختلفی به‌عنوان ریشه است. این قابلیت علاوه بر انعطاف‌پذیری امکان مدیریت بهتر فایل‌ها را فراهم می‌آورد. لیست تنظیمات محیط در سرویس‌دهنده‌ی فایل نشان‌دهنده‌ی مسیر‌هایی است که فایل‌ها برای اشتراک در آن‌ها قرار دارند. برای پیدا کردن یک فایل به ترتیب تعریف مسیر‌ها در فایل پیکربندی جستجو انجام می‌شود. به‌عنوان‌مثال در پیکربندی ‏2‑3 که چگونگی تعریف مسیر‌ها در فایل پیکربندی master قرارگرفته است، درصورتی‌که بخواهیم به آدرس salt://httpd/httpd.conf دسترسی داشته باشیم ابتدا مسیر /srv/salt/base/httpd/httpd.conf مورد جستجو قرار می‌گیرد و در صورت پیدا نشدن، مسیر /srv/salt/failover/httpd/httpd.conf بررسی می‌شود. استفاده از مسیر‌های مختلف، تنها به دلیل جداسازی منطقی فایل‌ها از یکدیگر است.file_roots:base:- /srv/salt/base- /srv/salt/failoverپیکربندی ‏2‑3پیکربندی چندین مسیر به‌عنوان file_roots1-5-2 سرویس‌دهنده‌ی فایل با استفاده از gitfsسامانه‌ی سرویس‌دهنده‌ی فایل در salt به‌صورت پیمانه‌ای معرفی شده است. این ویژگی قابلیت تجمیع این سامانه با سرویس‌دهنده‌های مختلف فایل و منابع خارج از سامانه‌ی salt را فراهم می‌آورد. به‌عنوان‌مثال توانایی استفاده از ابزار‌هایی نظیر git، mercurial و Subversion امکان اتصال و مدیریت ‌فایل‌ها از طریق دیگر مخازن را فراهم می‌آورد.برای استفاده از gitfs در سامانه، می‌توان از یکی از کتابخانه‌های pygit2، Dulwich و یا Gitpython استفاده کرد. برای پیکربندی این بخش می‌توان مطابق مراحل زیر عمل کرد:1- نصب pygit2 مطابق قطعه برنامه ‏2‑21 .apt-get install python-pygit2قطعه برنامه ‏2‑21نصب pygit22- تعریف git به‌عنوان سرویس‌دهنده در فایل پیکربندی master مطابق پیکربندی ‏2‑4.fileserver_backend:- gitپیکربندی ‏2‑4تعریف git به‌عنوان سرویس‌دهنده3- تعیین مخزن و راهکار ارتباط با در git در فایل پیکربندی master مطابق پیکربندی ‏2‑5 .gitfs_remotes:- git@github.com:user/repo.git:- pubkey: /root/.ssh/id_rsa.pub- privkey: /root/.ssh/id_rsa- passphrase: myawesomepassphraseپیکربندی ‏2‑5تعیین مخزن git در فایل پیکربندی4- راه‌اندازی مجدد master.1-6 پیمانه‌های اجراییپیمانه‌های اجرایی که هسته‌ی اصلی فعالیت‌های Salt را تشکیل می‌دهند، وظیفه‌ی اجرای دستورات و ارتباط با minions ها را بر عهده دارند. این پیمانه‌ها کتابخانه‌ای از فعالیت‌ها را ایجاد می‌کنند که دیگر پیمانه‌ها نظیر سامانه‌ی مدیریت وضعیت در فعالیت‌های خود از آن‌ها استفاده می‌کنند.ساختار این پیمانه‌ها باز و قابل‌گسترش است و تنها محدودیت آن‌ها، بازگرداندن یک شی JSON ترتیب پذیر است. در ادامه برخی از مفاهیم مورد استفاده در ساختار پیمانه‌های اجرای و نمونه‌هایی از این پیمانه‌ها را بررسی می‌کنیم.1-6-1 امکانات توسعه‌ی پیمانه‌های اجراییتوسعه و استفاده از پیمانه‌های اجرایی بسیار ساده است. تنها کافی ست پیمانه‌های نوشته‌شده در محیط‌های Python یا Cython را در مسیر _modules/ در مسیر ریشه‌ی مشخص‌شده‌ی file_roots که در فایل پیکربندی master تعیین‌شده است قرار داده و با یکی از دستورات زیر پیمانه را به minion ها برای اجرا انتقال دهیم.· State.highstate· Saltutil.sync_modules· Saltutil.sync_allبه‌طورمعمول اسم فایل نشان‌دهنده‌ی نام پیمانه است. درصورتی‌که پیمانه دارای خطا باشد، سامانه بدون بارگذاری پیمانه و بدون مشکل به ادامه‌ی فعالیت‌های خود می‌پردازد و از پیمانه‌ی دارای خطا صرف‌نظر می‌شود. اگر پیمانه در محیط Cython نوشته‌شده باشد، فایل باید به‌صورت .pyx نام‌گذاری گردد. در این شرایط روند کامپایل پیمانه به‌صورت خودکار صورت می‌گیرد.1-6-1-1 ارتباط بین پیمانه‌هاتمام پیمانه‌ها به یکدیگر دسترسی دارند و می‌توانند توابع یکدیگر را فراخوانی کنند. این ارتباط از طریق قرار دادن متغیر __salt__ در پیمانه بعد از بارگذاری در minionصورت می‌گیرد. این متغیر که از نوع dictionary است شامل تمام توابع موجود است. کلید این متغیر رشته‌ای است که نشان‌دهنده‌ی نام پیمانه و نام تابع و مقدار آن تابع متناظر با رشته است. به‌عنوان‌مثال تابع قطعه کد ‏2‑1می‌تواند در یک پیمانه دستور bar را بر روی همان minion اجرا کند.def foo(bar):return __salt__['cmd.run'](bar)قطعه کد ‏2‑1فراخوانی تابع از پیمانه‌ای دیگر1-6-1-2 اطلاعات افزوده‌شده به پیمانه در زمان بارگذاریبرخی اطلاعاتی که به‌صورت پویا برای اجرای پیمانه‌ها فراهم می‌شود عبارت‌اند از:1. Grains:این اطلاعات که در بخش ‏2-4-3 آورده شده است در داده‌ساختار__grains__ قرار دارد. این داده‌ساختار که از نوع dictionary است، می‌تواند به‌وسیله‌ی تمام اشیاء قابل فراخوانی در پیمانه‌های پایتون مورداستفاده قرار گیرد. به‌عنوان‌مثال برای دسترسی به idماشینی که minion بر روی آن اجراشده است می‌توان از مقدار __grains__['id'] استفاده کرد.2. پیکربندی پیمانه:علاوه بر اطلاعات grain ، ابزار salt امکان انتقال مقادیر از طریق متغیرهای پیکربندی موجود در فایل پیکربندی minion را به پیمانه‌ها می‌دهد.1-6-1-3 پیمانه‌های مجازیدر برخی موارد پیمانه‌ها به‌صورت کلی پیاده‌سازی می‌شود تا بتوان از پیاده‌سازی‌های مختلف متناسب با نوع ماشین مقصد برای انجام فعالیت‌ها استفاده کرد. این قابلیت امکان ایجاد دستوراتی کلی و مستقل از ماشین‌ مقصد فراهم می‌آورد.یکی از مثال‌های پرکاربرد این روش، پیاده‌سازی پیمانه‌ی مدیریت بسته‌های نرم‌افزاری است. تمامی پیمانه‌های مدیریت بسته در salt شامل یک تابع __virtual__ هستند که مشخص‌کننده‌ی پیمانه‌ی جایگزین در minion است. این امکان ایجاد واسطی یکسان در تمامی توزیع‌هایی که از هر یک از ابزار‌ها apt-get ، Yum ، pacman و at بهره می‌برند، فراهم می‌آورد.1-6-2 نمونه پیمانه‌ی اجراییدر این بخش روند توسعه و به‌کارگیری یک پیمانه‌ی ساده با نام TUsalt را بررسی می‌کنیم. در سامانه‌ی مورد آزمایش دو ماشین با نام‌های ubuntu231 و ubuntu195 در ارتباط با master هستند.1-6-2-1 کد پیمانه اجرایی TUsaltTestهمان‌طور که در قطعه کد ‏2‑2پیمانه‌ی اجرایی آزمون TUsaltTest قابل‌مشاهده است، پیمانه‌ی آزمون تنها یک تابع ساده با نام echo دارد که رشته‌ی ورودی را به همان صورت بازمی‌گرداند. این عملکرد مشابه تابع test.echo است.# -*- coding: utf-8 -*-'''Module for running arbitrary tests'''# Import Salt libsimport saltimport salt.versionimport salt.loaderdef echo(text):return textقطعه کد ‏2‑2 پیمانه‌ی اجرایی آزمون TUsaltTest1-6-2-2 انتقال به ماشین‌ مقصدپس از نوشتن پیمانه مطابق ‏2-6-2-1 فایل پیمانه را در مسیر /srv/salt/ که در فایل پیکربندی به‌عنوان یکی از file_roots ها مشخص شده است در پوشه‌ی _modules قرار می‌دهیم. در شکل ‏2‑6 محتوی این پوشه نشان داده شده است. تا زمانی که دستور هم‌زمان‌سازی پیمانه‌ها به ماشین‌ها داده نشود، پیمانه‌ها قابل فراخوانی نیستند. برای نشان داده این امر در اینجا ما تنها بر روی ماشین ubuntu231 همزمان سازی را انجام می‌دهیم و انتظار داریم که پیمانه تنها بر روی این ماشین قابل‌اجرا باشد.شکل ‏2‑6 محتوی مسیر _modules و انتقال پیمانه‌ی آزمون به یکی از ماشین‌ها1-6-2-3 اجرای دستور آزمونپس از انتقال و هم‌زمان‌سازی ماشین‌ها مطابق شکل ‏2‑7 پیمانه را اجرا می‌کنیم. همان‌طور که از نتیجه‌ی اجرا مشخص است، تنها ماشین با نام Ubuntu 231 که مراحل همزمان سازی بر روی آن انجام شده است قادر به اجرای صحیح پیمانه‌ی آزمون است. و ماشین دیگر با نام ubuntu195 قادر به اجرای برنامه‌ی آزمون نیست.شکل ‏2‑7 اجرای پیمانه‌ی آزمون بر روی ماشین‌ها1-6-3 برخی از پیمانه‌های اجراییبا توجه به تنوع پیمانه‌های توسعه‌یافته در اینجا به برخی از پیمانه‌های پرکاربرد salt خواهیم پرداخت.1-6-3-1 پیمانه atبا استفاده از این پیمانه می‌توان به کمک ابزار at در سیستم‌عامل لینوکس وظایفی را برای انجام در آینده برنامه‌ریزی و زمان‌بندی کرد. در قطعه برنامه ‏2‑22برخی دستورات پیمانه‌ی at آورده شده است. خطوط 1 و 2 این قطعه کد شیوه‌ی افزودن کار جدید را نشان می‌دهد. خط سوم لیست‌ کارهای زمان‌بندی‌شده و خط چهارم وضعیت یک کار را نشان می‌دهد. خط پنجم تمام‌کارهای زمان‌بندی‌شده و خط ششم کار‌هایی که شماره آن‌ها به‌عنوان پارامتر داده‌شده را از لیست حذف می‌کند.1. salt '*' at.at 12:05am '/sbin/reboot' tag=reboot2. salt '*' at.at '3:05am +3 days' 'bin/myscript' tag=nightly runas=jim3. salt '*' at.atq4. salt '*' at.jobcheck 5. salt '*' at.atrm all6. salt '*' at.atrm .. قطعه برنامه ‏2‑22برخی دستورات پیمانه‌ی atعلاوه بر این پیمانه، راهکار‌های دیگری نیز برای زمان‌بندی انجام کار موجود است که در ادامه بررسی خواهد شد.1-6-3-2 پیمانه augeas_cfgپیمانه augeas ابزاری برای ویرایش تنظیمات است. این ابزار با پویش فایل‌های پیکربندی، ساختاری درختی از متغیر‌های این فایل‌ها ایجاد می‌کند. این ابزار با به‌کارگیری زبانی منحصر به دامنه ساختار فایل‌های پیکربندی را توصیف می‌کند. این ابزار یک واسط برنامه‌نویسی برای پیکربندی در linux فراهم می‌آورد. هدف از این ابزار ارائه‌ی روش و جایگزین مطمئن برای دیگر روش‌های مستقل تغییر فایل‌های پیکربندی با استفاده از grep، sed و awk است.برای نصب پیش‌نیازهای این پیمانه بر روی ماشین‌های مقصد می‌توان قطعه برنامه ‏2‑23 استفاده کرد. خط سوم از این قطعه کد برای بررسی صحت نصب پیش‌نیاز‌ها است و در صورت وجود ابزار‌های موردنیاز به‌درستی اجرا می‌شود.1. salt '*' pkg.install python-augeas2. salt '*' pkg.install augeas-tools3. salt '*' cmd.run 'python -c "from augeas import Augeas"'قطعه برنامه ‏2‑23نصب پیش‌نیازهای موردنیاز برای پیمانه‌ی augeasدر قطعه برنامه ‏2‑24 برخی از کاربرد‌های این پیمانه آورده شده است. در خط اول این قطعه کد، دستورات ابزار augeas به‌صورت مستقل و کامل بر روی ماشین مقصد اجرا می‌شود. در خط دوم مقدار اولین IPدر فایل پیکربندی /etc/hosts در minion مقصد نشان داده می‌شود. خط سوم لیست زیر‌شاخه‌های موجود در فایل پیکربندی /etc/passwd را نشان‌ می‌دهد. خط چهارم مقدار متناظر با ssh در مسیر /etc/services/service-nameرا نشان می‌دهد. خط پنجم نیز مقدار net.ipv4.conf.all.log_martiansو مقدار متناظر با آن را از فایل پیکربندی /etc/sysctl.conf حذف می‌کند. خط ششم از این قطعه کد مقدار IP و رشته‌ی خط اول در فایل /etc/hosts را برابر 192.168.1.1 و test قرار می‌دهد.1. salt '*' augeas.execute /files/etc/redis/redis.conf commands='["set bind 0.0.0.0", "set maxmemory 1G"]'2. salt '*' augeas.get /files/etc/hosts/1/ ipaddr3. salt '*' augeas.ls /files/etc/passwd4. salt '*' augeas.match /files/etc/services/service-name ssh5. salt '*' augeas.remove /files/etc/sysctl.conf/net.ipv4.conf.all.log_martians6. salt '*' augeas.setvalue /files/etc/hosts/01/ipaddr 192.168.1.1 /files/etc/hosts/01/canonical testقطعه برنامه ‏2‑24برخی امکانات پیمانه‌ی augeas1-6-3-3 پیمانه apacheبه‌وسیله‌ی پیمانه‌ی apache می‌توان برخی از تنظیمات سرویس‌دهنده‌ی وب apacheرا انجام داد. در قطعه برنامه ‏2‑25 برخی تنظیمات نظیر افزودن و حذف کاربران و نمایش پیمانه‌های بارگذاری شده و تغییر پیکربندی را انجام داد.1. salt '*' apache.modules2. salt '*' apache.servermods3. salt '*' apache.signal restart4. salt '*' apache.useradd /etc/httpd/htpasswd larry badpassword5. salt '*' apache.userdel /etc/httpd/htpasswd larry6. salt '*' apache.config /etc/httpd/conf.d/ports.conf config="[{'Listen': '22'}]"قطعه برنامه ‏2‑25 برخی موارد استفاده از پیمانه‌ی apache1-6-3-4 پیمانه pkgاین پیمانه‌ی مجازی در سامانه‌های مختلف به‌وسیله‌ی یکی از پیمانه‌های زیر جایگزین می‌شود:· salt.modules.aptpkg· salt.modules.brew· salt.modules.ebuild· salt.modules.freebsdpkg· salt.modules.openbsdpkg· salt.modules.pacman· salt.modules.pkgin· salt.modules.pkgng· salt.modules.pkgutil· salt.modules.solarispkg· salt.modules.win_pkg· salt.modules.yumpkg· salt.modules.zypperاین پیمانه‌ با توجه به سامانه‌ی مقصد می‌تواند یکی از عملیات‌هایی نظیر نصب، حذف بسته‌های نرم‌افزاری و مخازن نرم‌افزار را انجام دهد. در قطعه برنامه ‏2‑26 برخی از کاربرد‌های این پیمانه در ارتباط با مدیریت مخازن بسته‌ها آورده شده است. در خطوط اول تا سوم این قطعه برنامه چگونگی حذف و تغییر مخازن آورده شده است. در خطوط پنجم روش نمایش لیست مخازن و به‌روزرسانی پایگاه‌داده بسته‌ها آورده شده است.1. salt '*' pkg.del_repo "myrepo definition"2. salt '*' pkg.mod_repo 'myrepo definition' uri=http://new/uri3. salt '*' pkg.mod_repo 'myrepo definition' comps=main,universe4. salt '*' pkg.list_repos5. salt '*' pkg.refresh_dbقطعه برنامه ‏2‑26 کاربرد‌های پیمانه‌ی pkgدر مدیریت مخازندر قطعه برنامه ‏2‑27 برخی کاربرد‌های پیمانه‌ی pkg در نصب، حذف و به‌روزرسانی بسته‌ها آورده شده است.1. salt '*' pkg.autoremove2. salt '*' pkg.file_list httpd postfix3. salt '*' pkg.install 4. salt '*' pkg.install sources='[{"foo": "salt://foo.deb]'5. salt '*' pkg.list_pkgs6. salt '*' pkg.list_upgrades7. salt '*' pkg.purge 8. salt '*' pkg.remove 9. salt '*' pkg.upgradeقطعه برنامه ‏2‑27کاربرد‌های پیمانه‌ی pkg در مدیریت بسته‌ها1-6-3-5 پیمانه blockdevبرای مدیریت دستگاه‌های ذخیره‌سازی بلوکی در سیستم‌عامل لینوکس می‌توان از پیمانه‌ی blockdev استفاده کرد. به‌عنوان‌مثال در صورت تغییر حجم پارتیشن می‌توان با استفاده از خط اول قطعه برنامه ‏2‑28 حجم فایل‌سیستم پارتیشن sda1 به‌اندازه پارتیشن تغییر کند. با استفاده از خطوط دوم و سوم نیز دستگاه تیون و وایپ می‌شود.1. salt '*' blockdev.resize2fs /dev/sda12. salt '*' blockdev.tune /dev/sda1 read-ahead=1024 read-write=True3. salt '*' blockdev.wipe /dev/sda1قطعه برنامه ‏2‑28 کاربرد‌های پیمانه‌ی blockdevدر مدیریت دستگاه‌های ذخیره‌سازی بلوکی1-6-3-6 پیمانه bridgeقابلیت bridge به‌عنوان بخشی از تنظیمات شبکه به‌وسیله‌ی پیمانه‌ی bridge در ابزار salt قابل پیکربندی است. همان‌طور که در قطعه برنامه ‏2‑29 قابل‌مشاهده است، با استفاده از این پیمانه قادر به ساخت و حذف bridgeو واسط‌های شبکه از bridgeخواهیم بود.1. salt '*' bridge.add br02. salt '*' bridge.addif br0 eth03. salt '*' bridge.delete br04. salt '*' bridge.delif br0 eth05. salt '*' bridge.interfaces br06. salt '*' bridge.list7. salt '*' bridge.show br08. salt '*' bridge.stp br0 enable9. salt '*' bridge.stp br0 disableقطعه برنامه ‏2‑29 برخی کاربرد‌های پیمانه‌ی bridge1-6-3-7 پیمانه btrfsسیستم‌فایل btrfs به‌عنوان یکی از سیستم‌فایل‌های پرکاربرد می‌تواند به‌وسیله‌ی پیمانه‌ی btrfsمدیریت شود. در قطعه برنامه ‏2‑30 برخی کاربرد‌های این پیمانه نظیر ساخت فایل‌سیستم، mount کردن و تبدیل فایل‌سیستم‌های دیگر به این سیستم‌فایل را مشاهده کرد.1. salt '*' btrfs.add /mountpoint /dev/sda1 /dev/sda22. salt '*' btrfs.convert /dev/sda1 permanent=True3. salt '*' btrfs.defragment /path/on/filesystem4. salt '*' btrfs.mkfs /dev/sda15. salt '*' btrfs.resize /mountpoint size=+1g6. salt '*' btrfs.usage /your/mountpointقطعه برنامه ‏2‑30 برخی کاربرد‌های پیمانه‌ی btrfs1-6-3-8 پیمانه cmdmodیکی از پیمانه‌های مهم ابزار salt پیمانه‌ی cmdmod است. این پیمانه قادر به اجرای دستورات و قطعه کد‌ در محیط مفسر‌های مختلف و دریافت نتیجه‌ی اجرای دستورات است. به‌عنوان‌مثال در خط اول از قطعه برنامه ‏2‑31 یک دستور در مفسر rubyاجرا می‌شود. در خط چهارم از این قطعه کد یک برنامه اجرا می‌شود و در خطوط 6 و 7 خروجی‌های استاندار برنامه دریافت می‌شود. همچنین در خط 8 و 9 یک قطعه کد اجرایی که در سرویس‌دهنده‌ی فایل masterقرار دارد بر روی تمام ماشین‌های minion اجرا می‌شود.1. salt '*' cmd.exec_code ruby 'puts "cheese"'2. salt '*' cmd.has_exec cat3. salt '*' cmd.retcode "grep f" stdin='one\ntwo\nthree\nfour\nfive\n'4. salt '*' cmd.run "ls -l | awk '/foo/{print \$2}'"5. salt '*' cmd.run_chroot /var/lib/lxc/container_name/rootfs 'sh /tmp/bootstrap.sh'6. salt '*' cmd.run_stderr "ls -l | awk '/foo/{print \$2}'"7. salt '*' cmd.run_stdout "grep f" stdin='one\ntwo\nthree\nfour\nfive\n'8. salt '*' cmd.script salt://scripts/runme.sh stdin='one\ntwo\nthree\nfour\nfive\n'9. salt '*' cmd.script_retcode salt://scripts/runme.sh10. salt '*' cmd.which catقطعه برنامه ‏2‑31 اجرای دستورات و قطعه کد با استفاده از cmdmod1-6-3-9 پیمانه cronیکی دیگر از پیمانه‌هایی که امکان زمان‌بندی و مدیریت اجرای برنامه‌ها در آینده را در اختیار می‌گذارد، پیمانه‌ی cron است. این پیمانه که واسطی برای ابزار cron است قادر به استفاده از تمام ویژگی‌های این ابزار است که برخی از این کاربرد‌ها در قطعه برنامه ‏2‑32 آورده شده است.1. salt '*' cron.list_tab root2. salt '*' cron.rm_job root /usr/local/weekly3. salt '*' cron.set_job root '*' '*' '*' '*' 1 /usr/local/weekly4. salt '*' cron.rm_env root MAILTO5. salt '*' cron.set_env root MAILTO user@example.com6. salt '*' cron.set_special root @hourly 'echo foobar'7. salt '*' cron.write_cron_file root /tmp/new_cronقطعه برنامه ‏2‑32 برخی کاربرد‌های پیمانه‌ی cron1-6-3-10 پیمانه ipغالب تنظیمات مربوط به شبکه‌ و واسط‌های شبکه را می‌توان با استفاده از پیمانه‌ی ip قابل مدیریت است. این پیمانه که در قطعه برنامه ‏2‑33 برخی از کاربرد‌های این پیمانه نظیر تغییر مسیریابی، تغییر وضعیت واسط شبکه آورده شده است.1. salt '*' ip.apply_network_settings2. salt '*' ip.build_bond bond0 mode=balance-alb3. salt '*' ip.build_interface eth0 eth 4. salt '*' ip.build_network_settings 5. salt '*' ip.build_routes eth0 6. salt '*' ip.down eth0 eth7. salt '*' ip.get_interface eth08. salt '*' ip.get_network_settings9. salt '*' ip.up eth0 ethقطعه برنامه ‏2‑33 برخی کاربرد‌های پیمانه‌ی ip1-6-3-11 پیمانه‌ iptablesیکی از ابزارهای مهم در سیستم‌عامل لینوکس iptables است. پیمانه‌ی iptables امکان مدیریت قوانین و زنجیره‌های قوانین را در اختیار می‌گذارد. برخی از کاربرد‌های این پیمانه نظیر حذف و اضافه کردن قوانین و زنجیره‌ها در قطعه برنامه ‏2‑34 آورده شده است.1. salt '*' iptables.append filter INPUT rule='-m state --state RELATED,ESTABLISHED -j ACCEPT'2. salt '*' iptables.build_rule match=state connstate=RELATED,ESTABLISHED jump=ACCEPT3. salt '*' iptables.check filter INPUT rule='-m state --state RELATED,ESTABLISHED -j ACCEPT'4. salt '*' iptables.check_chain filter INPUT5. salt '*' iptables.delete filter INPUT position=36. salt '*' iptables.delete filter INPUT rule='-m state --state RELATED,ESTABLISHED -j ACCEPT'7. salt '*' iptables.delete_chain filter CUSTOM_CHAIN8. salt '*' iptables.flush filter INPUT9. salt '*' iptables.get_policy filter INPUT10.salt '*' iptables.get_rules11.salt '*' iptables.get_saved_policy filter INPUT conf_file=/etc/iptables.saved12.salt '*' iptables.get_saved_rules13.salt '*' iptables.insert filter INPUT position=3 rule='-m state --state RELATED,ESTABLISHED -j ACCEPT'14.salt '*' iptables.new_chain filter CUSTOM_CHAIN15.salt '*' iptables.save /etc/sysconfig/iptables16.salt '*' iptables.set_policy filter INPUT ACCEPTقطعه برنامه ‏2‑34 برخی کاربرد‌های پیمانه‌ی iptables1-6-3-12 پیمانه kmodبرای مدیریت پیمانه‌های بارگذاری شده در کرنل لینوکس می‌توان از پیمانه‌ی kmodاستفاده کرد. این پیمانه قابلیت نمایش پیمانه‌های بارگذاری شده، بارگذاری و حذف پیمانه‌ها را فراهم می‌آورد. که در قطعه برنامه ‏2‑35 برخی کاربردهای پیمانه‌ی kmod آورده شده است.1. salt '*' kmod.available2. salt '*' kmod.check_available kvm3. salt '*' kmod.is_loaded kvm4. salt '*' kmod.load kvm5. salt '*' kmod.lsmod6. salt '*' kmod.mod_list7. salt '*' kmod.remove kvmقطعه برنامه ‏2‑35 برخی کاربردهای پیمانه‌ی kmod1-6-3-13 پیمانه linux_sysctlبرای مشاهده و تغییر متغیرهای سیستم‌عامل لینوکس که از طریق ابزار sysctl قابل‌دسترسی است می‌توان از پیمانه‌ی linux_sysctl استفاده کرد. در قطعه برنامه ‏2‑36 برخی کاربرد‌های پیمانه‌sysctl آورده شده است.salt '*' sysctl.assign net.ipv4.ip_forward 1salt -G 'kernel:Linux'sysctl.default_configsalt '*' sysctl.get net.ipv4.ip_forwardsalt '*' sysctl.persist net.ipv4.ip_forward 1salt '*' sysctl.showقطعه برنامه ‏2‑36 برخی کاربرد‌های پیمانه‌sysctl1-6-3-14 پیمانه nftablesیکی از ابزار‌های جدید در سیستم‌عامل لینوکس که از نسخه‌ی 3.13 کرنل لینوکس منتشر شده است، ابزار nftables است. این ابزار را می‌توان با استفاده از پیمانه‌ی nftablesمدیریت کرد. در قطعه برنامه ‏2‑37 برخی کاربرد‌های پیمانه‌ی nftables ازجمله افزودن و حذف قوانین از جداول پالایش این ابزار اشاره کرد.1. salt '*' nftables.append filter input rule='input tcp dport 22 log accept'2. salt '*' nftables.build_rule match=state connstate=RELATED,ESTABLISHED jump=ACCEPT3. salt '*' nftables.build_rule filter input command=insert position=3 full=True match=state state=related,established jump=accept4. salt '*' nftables.check filter input rule='input tcp dport 22 log accept'5. salt '*' nftables.check_chain filter input6. salt '*' nftables.check_table nat7. salt '*' nftables.delete filter input position=38. salt '*' nftables.delete filter input rule='input tcp dport 22 log accept'9. salt '*' nftables.delete_chain filter input10.salt '*' nftables.delete_table filter11. salt '*' nftables.flush filter12.salt '*' nftables.get_rule_handle filter input rule='input tcp dport 22 log accept'13. salt '*' nftables.insert filter input rule='input tcp dport 22 log accept'14.salt '*' nftables.insert filter input position=3 rule='input tcp dport 22 log accept'15.salt '*' nftables.new_chain filter input table_type=filter hook=input priority=016.salt '*' nftables.new_table filter17.salt '*' nftables.save /etc/nftablesقطعه برنامه ‏2‑37 برخی کاربرد‌های پیمانه‌ی nftables1-6-3-15 پیمانه serviceبه‌طورمعمول در سیستم‌عامل‌های مختلف ابزار‌های مختلفی برای سرویس‌دهنده‌ها وجود دارد. از این میان می‌توان به debian_service، upstart و system اشاره کرد. پیمانه‌ی service با فراهم آوردن واسطی یکپارچه می‌تواند وضعیت سرویس‌ها را در ماشین‌های مختلف مدیریت کند. در قطعه برنامه ‏2‑38 برخی قابلیت‌های مدیریت سرویس با استفاده از پیمانه service آورده شده است.1. salt '*' service.available 2. salt '*' service.get_all3. salt '*' service.missing 4. salt '*' service.reload 5. salt '*' service.restart 6. salt '*' service.start 7. salt '*' service.status [service signature]8. salt '*' service.stop قطعه برنامه ‏2‑38 برخی قابلیت‌های مدیریت سرویس با استفاده از پیمانه service1-6-3-16 پیمانه systemبرای تغییر وضعیت ماشین به run level های مختلف و یا راه‌اندازی مجدد آن می‌توان از پیمانه‌ی system استفاده کرد. در قطعه برنامه ‏2‑39 کاربرد‌هایی از تغییر وضعیت سیستم با استفاده از پیمانه‌ی system آورده شده است.1. salt '*' system.halt2. salt '*' system.init 33. salt '*' system.poweroff4. salt '*' system.reboot5. salt '*' system.shutdownقطعه برنامه ‏2‑39 کاربرد‌هایی از تغییر وضعیت سیستم با استفاده از پیمانه‌ی system1-7 بازگرداننده‌هایکی از ویژگی‌های مفید در معماری امکان انتقال پاسخ‌ها و نتیجه‌ی رخدادها از محیط minion ها به محیطی خارجی برای بررسی و تحلیل است. پیمانه‌های بازگرداننده تنظیمات خود را تنها یک‌بار و در زمان بارگذاری از minionها دریافت می‌کنند. به‌عبارت‌دیگر پیکربندی هر بازگرداننده در زمان بارگذاری minionها انجام می‌شود و بعد از آن تنها بازگرداننده فراخوانی و مورد استفاده قرار می‌گیرد.1-7-1 نحوه‌ی استفاده از بازگرداننده‌هابرای استفاده از قابلیت پیمانه‌های بازگرداننده می‌توان مطابق خط اول قطعه برنامه ‏2‑40 در تمامی دستورات از یک بازگرداننده بهره گرفت. همچنین می‌توان از چندین بازگرداننده برای یک دستور استفاده کرد.salt '*' test.ping --return redis_returnsalt '*' test.ping --return mongo_return,redis_return,cassandra_returnقطعه برنامه ‏2‑40 شیوه‌ی به‌کارگیری از پیمانه‌های بازگرداننده1-7-2 برخی بازگرداننده‌های پرکاربردبه دلیل معماری پیمانه‌ای ابزار salt بازگرداننده‌های متعددی توسعه یافته است ولی در اینجا تنها به برخی از این بازگرداننده‌ها خواهیم پرداخت.1-7-2-1 بازگرداننده‌ djangoاین بازگرداننده با استفاده از سامانه‌ی سیگنال در قالب کاری djangoمی‌تواند اطلاعات بازگردانده شده را به این قالب کاری انتقال دهد. این بر عهده‌ی توسعه‌دهنده‌ی در محیط djangoاست که با تعریف تابع اطلاعات دریافتی را پردازش کند. در قطعه کد ‏2‑3یک نمونه‌ی ساده از تابع قابل تعریف در قالب کاری django آورده شده است.import salt.returners.django_returnfrom django.dispatch import receiver@receiver(salt.returners.django_return, sender=returner)def returner_callback(sender, ret):print('I received {0} from {1}'.format(ret, sender))قطعه کد ‏2‑3 نمونه تابع قابل تعریف در django برای استفاده از بازگرداننده1-7-2-2 بازگرداننده‌ mysqlیکی از بازگرداننده های مهم، پیمانه‌ی پایگاه‌داده‌ی mysqlاست. پیکربندی این پیمانه در پیکربندی ‏2‑6 آورده شده است.mysql.host: 'salt'mysql.user: 'salt'mysql.pass: 'salt'mysql.db: 'salt'mysql.port: 3306پیکربندی ‏2‑6پیکربندی بازگرداننده‌ی mysqlهمچنین برای قرارگیری اطلاعات بازگردانده شده باید پیش از استفاده از بازگرداننده‌ی mysql پایگاه داده و جداول موردنیاز ساخته شود. برای اینکار می‌توان از قطعه کد ‏2‑4 بهره برد.CREATE DATABASE `salt`DEFAULT CHARACTER SET utf8DEFAULT COLLATE utf8_general_ci;USE `salt`;---- Table structure for table `jids`--DROP TABLE IF EXISTS `jids`;CREATE TABLE `jids` (`jid` varchar(255) NOT NULL,`load` mediumtext NOT NULL,UNIQUE KEY `jid` (`jid`)) ENGINE=InnoDB DEFAULT CHARSET=utf8;---- Table structure for table `salt_returns`--DROP TABLE IF EXISTS `salt_returns`;CREATE TABLE `salt_returns` (`fun` varchar(50) NOT NULL,`jid` varchar(255) NOT NULL,`return` mediumtext NOT NULL,`id` varchar(255) NOT NULL,`success` varchar(10) NOT NULL,`full_ret` mediumtext NOT NULL,`alter_time` TIMESTAMP DEFAULT CURRENT_TIMESTAMP,KEY `id` (`id`),KEY `jid` (`jid`),KEY `fun` (`fun`)) ENGINE=InnoDB DEFAULT CHARSET=utf8;---- Table structure for table `salt_events`--DROP TABLE IF EXISTS `salt_events`;CREATE TABLE `salt_events` (`id` BIGINT NOT NULL AUTO_INCREMENT,`tag` varchar(255) NOT NULL,`data` varchar(1024) NOT NULL,`alter_time` TIMESTAMP DEFAULT CURRENT_TIMESTAMP,`master_id` varchar(255) NOT NULL,PRIMARY KEY (`id`),KEY `tag` (`tag`)) ENGINE=InnoDB DEFAULT CHARSET=utf8;قطعه کد ‏2‑4 ساختار پایگاه‌داده برای استفاده از بازگرداننده‌ی mysqlپس از پیکربندی و ساخت پایگاه‌داده و جداول در mysql می‌توان با استفاده از قطعه برنامه ‏2‑41 اطلاعات برگردانده شده را به پایگاه داده انتقال داد.salt '*' test.ping --return mysqlقطعه برنامه ‏2‑41 شیوه‌ی استفاده از بازگرداننده mysql1-7-2-3 بازگرداننده‌ smtpبرای ارسال اطلاعات از طریق ایمیل و با استفاده از پروتکل smtpمی‌توان از پیمانه‌ی بازگرداننده‌ی smtp استفاده کرد. برای استفاده از این پیمانه باید موارد پیکربندی ‏2‑7 را در فایل پیکربندی master مشخص نمود.smtp.from (required)smtp.to (required)smtp.host (required)smtp.port (optional, defaults to 25)smtp.username (optional)smtp.password (optional)smtp.tls (optional, defaults to False)smtp.subject (optional, but helpful)smtp.gpgowner (optional)smtp.fields: id,funپیکربندی ‏2‑7موارد قابل استفاده در پیکربندی بازگرداننده‌ی smtp1-7-2-4 بازگرداننده‌ smsاین بازگرداننده با استفاده از رابط برنامه‌نویسی twilioمی‌تواند اطلاعات را از طریق پیام‌کوتاه انتقال دهد. در پیکربندی ‏2‑8 تنظیمات موردنیاز برای این بازگرداننده آورده شده است.twilio.sid: 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX'twilio.token: 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX'twilio.to: '+1415XXXXXXX'twilio.from: '+1650XXXXXXX'پیکربندی ‏2‑8 پیکریندی بازگرداننده‌ی sms1-7-2-5 بازگرداننده‌ syslogاین بازگرداننده می‌توان از syslog سیستم‌عامل به‌عنوان بازگرداننده استفاده کند. برای استفاده از این بازگرداننده می‌توان مطابق قطعه برنامه ‏2‑42 عمل کرد.salt '*' test.ping --return syslogقطعه برنامه ‏2‑42 استفاده از بازگرداننده‌ی syslog1-7-3 توسعه‌ی بازگردانندهیک بازگرداننده، پیمانه‌ای به زبان پایتون و شامل تابعی با نام returnerاست. این تابع باید یک پارامتر را که شامل اطلاعات برگردانده شده است، بپذیرد. در قطعه کد ‏2‑5 نمونه‌ای از یک برگرداننده‌ی ساده آورده شده است که نتیجه را به‌صورت داده‌های ترتیب‌پذیر با ساختار JSONبه سرویس‌دهنده‌ی redisانتقال می‌دهد.import redisimport jsondef returner(ret):'''Return information to a redis server'''# Get a redis connectionserv = redis.Redis(host='redis-serv.example.com',port=6379,db='0')serv.sadd("%(id)s:jobs" % ret, ret['jid'])serv.set("%(jid)s:%(id)s" % ret, json.dumps(ret['return']))serv.sadd('jobs', ret['jid'])serv.sadd(ret['jid'], ret['id'])قطعه کد ‏2‑5 نمونه بازگردانندهپس از توسعه‌ی بازگرداننده، باید فایل مربوطه را در پوشه‌ی _returners از مسیر متغیر file_roots در فایل پیکربندی master قرار داده و یکی از سه دستور زیر را برای انتقال به بازگرداننده به mimonها استفاده کرد:· salt ‘*’ state.highstate· salt ‘*’ saltutil.sync_returners· salt ‘*’ saltutil.sync_all1-7-4 برگرداننده‌ی رخدادبرای حداکثر کردن میزان نظارت بر تاریخچه‌ی رخداد‌ها می‌توان تمام نتایج تولید‌شده از رخداد‌های مختلف ایجاد‌شده را در master به یک بازگرداننده انتقال داد. برای فعال سازی این قابلیت می‌توان گزینه‌ی event_retrurn را در پیکربندی master تعیین کرد تا بازگرداننده‌ی مدیریت کننده‌ی رخداد‌ها مشخص شود.لازم به ذکر است که تمامی بازگرداننده‌ها قابلیت مدیریت نتایج رخداد‌ها را ندارند و تنها بازگرداننده‌هایی که در آن‌ها تابع event_return() تعریف شده است، در این بخش قابل استفاده هستند.1-8 مدیریت پیکربندییکی از مهمترین و پرکاربرد‌ترین ویژگی‌های salt ساختار مدیریت پیکربندی یا وضعیت است. در این بخش، با توجه به نقش‌های هر ماشین و نیازمندی‌های آن، بر پیکربندی هر minionنظارت می‌گردد. این نظارت از طریق اعمال دسته‌ای دستورات با توجه به نقش ماشین انجام می‌شود.هسته‌ی اصلی این ساختار که فایل‌های sls هستند. این فایل‌ها شامل داده‌ها و تنضیمات و دستوراتی هستند که می‌توانند بر روی minionها اعمل شوند. فایل‌های sls در واقع داده‌ساختاری شامل انواع مختلفی از dictionary، لیست و رشته است. این معماری برای فایل‌ امکان درک و گسترش‌پذیری این فایل‌ها را افزایش می‌دهد.1-8-1 Top Fileاین فایل برای مشخص کردن نگاشت پیمانه‌های sls به minionها بکار می‌رود. این فایل مشخص می‌کند که هر گره از چه محیطی استفاده کند. تعریف محیط‌ها به‌صورت مفهومی درخت مسیرها را مرتب سازماندهی می‌کند. محیط‌ها در Top file با مسیر‌های ریشه در فایل پیکربندی masterدر تعریف می‌شوند. به‌عنوان‌مثال اگر پیکربندی مسیر ریشه به‌صورت پیکربندی ‏2‑9 و پیکربندی ‏2‑10 تعریف top file باشد، مشاهده می‌شود که به ازای هر محیط در top fileیک نگاشت از minion ها به فایل‌های وضعیت وجود دارد. ازآنجایی‌که هر چیزی در ابزار salt یک فایل است، محیط نیز یک فایل است. همان‌طور که در پیکربندی ‏2‑10 مشاهده می‌شود از روش‌های مختلفی می‌توان برای نگاشت بین ماشین‌ها و وضعیت‌ها استفاده کرد. تمامی روش‌هایی که در بخش ‏2-4 بیان شد در انتخاب ماشین‌های مقصد در این بخش قابل استفاده است.file_roots:base:- /srv/salt/basedev:- /srv/salt/devqa:- /srv/salt/qaprod:- /srv/salt/prodپیکربندی ‏2‑9 تعریف فایل پیکربندی masterbase:'*':- ldap-client- networking- salt.minion'salt-master*':- salt.master'^(memcache|web).(qa|prod).loc$':- match: pcre- nagios.mon.web- apache.server'os:Ubuntu':- match: grain- repos.ubuntu'os:(RedHat|CentOS)':- match: grain_pcre- repos.epel'foo,bar,baz':- match: list- database'somekey:abc':- match: pillar- xyzdev:'webserver*dev*':- webserver'db*dev*':- dbqa:'webserver*qa*':- webserver'db*qa*':- dbprod:'webserver*prod*':- webserver'db*prod*':- dbپیکربندی ‏2‑10تعریف محیط در Top Fileدر پیکربندی ‏2‑10 تمام ماشین‌ها وضعیت مربوط به ldap-client، شبکه و minionها را دریافت می‌کنند. هر ماشینی که با نام salt-masterشروع شود تنظیمات master را می‌گیرد. همچنین هر minionکه نام آن با “^(memcache|web).(qa|prod).loc$” تطابق یابد تنظیمات nagios.mon.web و apache.serverرا دریافت می‌کند. تمام ماشین‌های با سیستم‌عامل Ubuntuوضعیت repos.ubuntu و ماشین‌های با سیستم‌عامل CentOSو RHEL وضعیت مربوط به repos.epelرا دریافت می‌کنند. Minionهای foo ، bar و baz تنظیمات databaseرا دریافت می‌کنند. هر ماشینی که در pillarخود داده ای با کلید somkey با مقدار abc داشته باشد، وضعیت xyz را دریافت می‌کند. به همین ترتیب محیط‌های dev ، qa و prod نیز مقداردهی می‌شوند.1-8-2 تعریف فایل‌های slsقالب دستورات به‌صورت پیش‌فرض برای تعریف فایل‌های وضعیت yaml و jinja است. در پیکربندی ‏2‑11 یک نمونه وضعیت آورده شده است. در این پیکر‌بندی که با عنوان apacheدر فایل top معرفی خواهد شد درصورتی‌که بسته‌ی apacheنصب نباشد، آن را نصب و راه‌اندازی می‌کند. خط اول این پیکربندی نشان‌دهنده‌ی نام شناسایی داده‌ها را بیان می‌کند. در خط دوم و سوم فراخوانی توابعی از پیمانه‌های وضعیت را نشان می‌دهد. این توابع به‌صورت . مشخص می‌شود. به این ترتیب در خط دوم پیمانه‌ی وضعیت pkg.installed از نصب بودم یک بسته‌ی نرم‌افزار با استفاده از ابزار مدیریت بسته‌ بر روی ماشین مقصد اطمینان حاصل می‌کند. در خط سوم نیز از در حال اجرا بودن سرویس اطمینان حاصل می‌کند. ازآنجایی‌که امکان دارد یک بسته‌ی نرم‌افزار نصب نباشد، در خط چهارم پیش‌نیاز وضعیت در حال اجرا بودن سرویس را نصب بودن بسته‌ی apache اعلام می کند. به‌عبارت‌دیگر از بسته نرم‌افزاری نصب نباشد، ابتدا آن را نصب می‌کند و سپس وضعیت آن را به حالت در حال اجرا تغییر می‌دهد.apache:pkg.installed: []service.running:- require:- pkg: apacheپیکربندی ‏2‑11 نمونه‌ای ساده از فایل وضعیتعلاوه بر در حال اجرا بودن، ضرورت پیگیری روند تفییرات پیکربندی سرویس و بروز رسانی آن به‌صورت پویا احساس می‌گردد. در پیکربندی ‏2‑12 حالت تکمیل‌تر شده‌ی پیکربندی ‏2‑11 آورده شده است. خطوط یک تا پنجم مشابه پیکربندی ‏2‑11 است. در ادامه در خطوط 7 و 8 علاوه حالتی نظارتی بر روی فایل پیکربندی /etc/httpd/conf/httpd.conf و کاربر apacheنیز نظارت اعمال می‌شود. به این صورت که خطوط 9 تا 14 فایل پیکربندی /etc/httpd/conf/httpd.conf به‌صورت مدیریت شده معرفی شده است. محتویات این فایل از مسیر salt://apache/httpd.conf دریافت می‌شود و کاربر و گروه مالک و سطح دسترسی آن مشخص شده است. به این ترتیب در صورت تغییر محتوای salt://apache/httpd.conf تمام ماشین‌هایی که این پیکربندی بر روی آن‌ها اعمال شده است، فایل پیکربندی /etc/httpd/conf/httpd.conf آن‌ها بازنویسی و سرویس راه‌اندازی مجدد می‌شود. در خط هشتم نیز بر وجود کاربر apacheنظارت می‌شود. این نظارت از طریق خطوط 15 تا 21 اعمال می‌شود. این خطوط ویژگی‌های کاربر apache را مشخص می‌کند . در خط 21 نیز بر لزوم وجود گروه apache تاکید می‌کند. این الزام نیز در خطوط 22 تا 25 اعمال می‌شود.1. apache:2. pkg.installed: []3. service.running:4. - require:5. - pkg: apache6. - watch:7. - file: /etc/httpd/conf/httpd.conf8. - user: apache9. /etc/httpd/conf/httpd.conf:10. file.managed:11. - source: salt://apache/httpd.conf12. - user: root13. - group: root14. - mode: 64415. user.present:16. - uid: 8717. - gid: 8718. - home: /var/www/html19. - shell: /bin/nologin20. - require:21. - group: apache22. group.present:23. - gid: 8724. - require:25. - pkg: apacheپیکربندی ‏2‑12حالت کامل‌تر فایل وضعیتهمان‌طور که در مثال پیکربندی ‏2‑12 مشاهده شد، علاوه بر مدیریت متمرکز فایل‌های پیکربندی می‌توان بر تغییرات بخش‌های مختلف نظارت کرد.1-9 رخدادسامانه‌ی رخداد در ابزار salt برای انتقال اطلاعات وضعیت دستورات در حال اجرا و ارتباط برنامه‌های دیگر با ابزار salt است. این سامانه از دو بخش اصلی تشکیل شده است:· سوکت رخداد که رخداد‌ها را منتشر می‌کند.· کتابخانه‌ی رخداد که به رخداد‌ها گوش می دهد و به سامانه‌ی salt ارسال می‌کند.1-9-1 انواع رخدادبرخی از رخداد‌ها که در گذرگاه رخداد master قرار می‌گیرد عبارتند از:1. رخداد‌های احراز هویت: این رخداد‌ها در زمانی که minionها تست احراز‌ هویت را با master انجام می‌دهند، رخ می‌دهد.2. رخداد‌های شروع: این رخداد‌ها در زمانی که minionها به masterمتصل می‌شود، رخ می‌دهد.3. رخداد‌های کلید: این رخداد‌ها در زمان پذیرش و یا رد کلید رخ می‌دهد.4. رخداد‌های وظایف: این رخداد‌ها در زمان ارسال یک دستور به minionها رخ می‌دهد.5. رخداد‌های حضور: این رخداد‌ها به‌صورت دوره‌ای و وضعیت اتصال minionها را گزارش می‌دهد.1-9-2 گوش‌دادن برای دریافت رخدادهابرای دریافت رخداد‌ها و پردازش آن‌ها، خارج از ابزار saltمی‌توان مطابق قطعه برنامه ‏2‑43 رخداد‌ها را به‌صورت لحظه‌ای دریافت کرد و به‌وسیله‌ی ابزارة‌ای خارجی و قطعه کد‌های shell آن‌ها را پردازش کرد.salt-run state.event pretty=Trueقطعه برنامه ‏2‑43 دریافت رخداد‌ها در خط فرمانمی‌توان از طریق کتابخانه‌ی رخداد، به سامانه‌ی رخداد در ابزار salt دسترسی داشت. در قطعه کد ‏2‑6 راهکار دسترسی به رخداد‌ها از طریق محیط پایتون نمایش‌داده شده است. ازآنجایی‌که در برای دریافت رخداد‌ها این کتابخانه از سوکت‌های unix استفاده می‌کند، برای اتصال به سامانه، مسیر قرارگیری این سوکت‌ها که در فایل پیکربندی master با عنوان sock_dir مقدار‌دهی می‌شود، باید مشخص شود. رخداد‌ها از برچسب برای فراهم ساختن امکان پالایش رخدادها بهره می‌برد.import salt.configimport salt.utils.eventopts = salt.config.client_config('/etc/salt/master')event = salt.utils.event.get_event('master',sock_dir=opts['sock_dir'],transport=opts['transport'],opts=opts)while True:ret = sevent.get_event(full=True)if ret is None:continueif fnmatch.fnmatch(ret['tag'], 'salt/job/*/ret/*'):do_something_with_job_return(ret['data'])قطعه کد ‏2‑6 دریافت رخداد‌ها در پایتون1-9-3 ایجاد رخدادبرای ایجاد رخداد در خط فرمان می‌توان از طریق قطعه برنامه ‏2‑44 پیامی دلخواه را بر روی گذرگاه رخداد قرار داد.salt-call event.fire '{"data": "message to be sent in the event"}' 'tag'قطعه برنامه ‏2‑44 ایجاد رخداد در خط فرماناگر بخواهیم در پیمانه‌های اجرایی یک رخداد ایجاد کنیم، می‌توانیم مطابق قطعه کد ‏2‑7 رفتار کنیم.# /srv/salt/_modules/my_custom_module.pydef do_something():'''Do something and fire an event to the master when finishedCLI Example::salt '*' my_custom_module:do_something'''# do something!__salt__['event.send']('myco/my_custom_module/finished', {'finished': True,'message': "The something is finished!",})قطعه کد ‏2‑7 ایجاد رخداد در پیمانه‌ی اجراییهمچنین درصورتی‌که بخواهیم در ابزاری خارج از saltرخدادی ایجاد کنیم، مطابق قطعه کد ‏2‑8 می‌توان با استفاده از کتابخانه رخداد، این عمل را انجام داد.import salt.clientcaller = salt.client.Caller()caller.sminion.functions['event.send']('myco/myevent/success',{'success': True,'message': "It works!",})قطعه کد ‏2‑8 ایجاد رخداد در محیط پایتون1-9-4 سامانه واکنش‌گر[16]هدف از سامانه‌ی واکنش‌گر، ایجاد موتور منطقی برای انجام اعمالی مشخص، در صورت مشاهده‌ی رخداد مشخصی است. به‌عبارت‌دیگر این سامانه دو بخش رخداد و پیمانه‌های اجرایی را با یکدیگر تلفیق می‌کند.1-9-4-1 نگاشت رخداد به وضعیتنگاشت رخداد به فایل‌های sls در پیکربندی master انجام می‌شود. به‌صورت پیش‌فرض این پیکربندی در مسیر /etc/salt/master و یا /etc/salt/master.d/reactor.conf قرار دارد. در پیکربندی ‏2‑13 یک نمونه‌ی ساده از سامانه‌ی واکنش آورده شده است. در این پیکربندی به ازای اجرای تمام minionها فایل‌های start.slsو monitor.sls اجرای می‌شود. همچنین در صورت خاتمه‌ی فعالیت هر minion تمام فایلهای وضعیت موجود در پوشه‌ی destroy اجرا می‌شود. در عین حال اگر رخدادی از بیرون به سامانه اعمال شود، فایل وضعیت mycustom.slsاجرا می‌شود.reactor: # Master config section "reactor"- 'salt/minion/*/start': # Match tag "salt/minion/*/start"- /srv/reactor/start.sls # Things to do when a minion starts- /srv/reactor/monitor.sls # Other things to do- 'salt/cloud/*/destroyed': # Globs can be used to matching tags- /srv/reactor/destroy/*.sls # Globs can be used to match file names- 'myco/custom/event/tag': # React to custom event tags- salt://reactor/mycustom.sls # Put reactor files under file_rootsپیکربندی ‏2‑13 پیکربندی واکنش‌گر در فایل پیکربندی masterساختار فایل‌های واکنش بسیار شبیه فایل‌های وضعیت که در بخش ‏2-8 معرفی شد است و به‌صورت پیش‌فرض می‌تواند از قالب yaml و jinja باشد. تنها تفاوت این فایل‌ها در اضافه شدن دو متغیر tag و data به این فایل‌ها است که به‌صورت زیر تعریف می‌شوند:· متغیر tagکه مشخص کننده‌ی برچسب رخداد فعال شده است.· متغیر dataحاوی اطلاعات رخداد است.در قطعه کد ‏2‑9 نمونه‌ای ساده واکنش آورده شده است. در این قطعه کد از قالب jinja برای افزایش قابلیت واکنش استفاده شده است. به‌عنوان‌مثال تنها اگر id رخداد mysql1 باشد و یا به عبارتی رخداد به‌وسیله‌ی minion با نام mysql1 ایجاد شده باشد، واکنش موردنظر انجام می‌شود.{% if data['id'] == 'mysql1' %}highstate_run:local.state.highstate:- tgt: mysql1{% endif %}قطعه کد ‏2‑9 نمونه‌ای ساده فایل واکنش1-9-4-2 مثالی از سامانه‌ی واکنش‌گردر اینجا مثال هدف پذیرش خودکار احراز هویت برخی از minionهایی که به masterمتصل می‌شوند است. در این مثال تعدادی سرویس‌دهنده‌ی به‌صورت تصادفی آنلاین می‌شوند و در برخی از آن‌ها نیاز به پذیرش خودکار کلید‌ آن‌ها وجود دارد. در اینجا فرض بر این است که تمام ماشین‌هایی که نام آن‌ها با ‘ink’ شروع می‌شود باید پذیرفته شوند و دستور state.highstate بر روی آن‌ها اعمال شود.برای انجام این فعالیت در فایل پیکربندی master مطابق پیکربندی ‏2‑14 رخداد‌های با برچسب ‘salt/auth’ مورد پردازش قرار می‌گیرند. در این پیکربندی که در مسیر /etc/salt/master.d/reactor.conf قرار می‌گیرد، تمام رخ داد‌های احراز هویت را با استفاده از فایل واکنش auth-pending.sls و تمام رخداد‌های شروع ماشین‌هایی که نام آن‌ها با Ink شروع می‌شود را با فایل واکنش auth-accept.slsمدیریت می‌کند.reactor:- 'salt/auth':- /srv/reactor/auth-pending.sls- 'salt/minion/ink*/start':- /srv/reactor/auth-complete.slsپیکربندی ‏2‑14تنظیمات فایل پیکربندی master برای مثال اولدر قطعه کد ‏2‑10 واکنش نسبت به احراز هویت تعیین می‌شود. در بخش اول این واکنش اگر احراز هویت به‌درستی انجام نشد، کلید مربوط به آن minion حذف و با استفاده از ssh سرویس minion راه‌اندازی مجدد می‌شود. در بخش دو نیز در صورت رخداد درخواست احراز هویت از minion ای که نام آن با ‘ink’ شروع می‌شود.{# Ink server faild to authenticate -- remove accepted key #}{% if not data['result'] and data['id'].startswith('ink') %}minion_remove:wheel.key.delete:- match: {{ data['id'] }}minion_rejoin:local.cmd.run:- tgt: salt-master.domain.tld- arg:- ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no "{{ data['id'] }}" 'sleep 10 && /etc/init.d/salt-minion restart'{% endif %}{# Ink server is sending new key -- accept this key #}{% if 'act' in data and data['act'] == 'pend' and data['id'].startswith('ink') %}minion_add:wheel.key.accept:- match: {{ data['id'] }}{% endif %}قطعه کد ‏2‑10 فایل auth-pending.slsدر ادامه بعد از احراز هویت minion‌هایی که با نام ‘ink’ شروع می‌شود، رخداد start را ایجاد می‌کنند که در نیتجه‌ی آن با توجه به پیکربندی ‏2‑14 فایل auth.complete.slsاجرا می‌شود که محتویات این فایل در قطعه کد ‏2‑11 آورده شده است. همان‌طور که در این کد مشاهده می‌کنید، ماشینی که رخداد start را ایجاد کرده است، دستور state.highstateبر روی آن اجرا می‌شود و نتیجه‌ی آن از طریق بازگرداننده‌ی smtp به سرویس‌دهنده‌ی موردنظر انتقال داده می‌شود.{# When an Ink server connects, run state.highstate. #}highstate_run:local.state.highstate:- tgt: {{ data['id'] }}- ret: smtp_returnقطعه کد ‏2‑11فایل auth-complete.sls1-10 رابط برنامه‌نویسی پایتونبه‌صورت ساده می‌توان با استفاده از قطعه کد ‏2‑12 دستورات را بر روی master به minionها صادر کرد. با استفاده از این قطعه کد بر روی تمام ماشین‌ها دستور whoami اجرا خواهد شد.import salt.clientlocal = salt.client.LocalClient()local.cmd('*', 'cmd.run', ['whoami'])قطعه کد ‏2‑12 استفاده از رابط برنامه‌نویسی پایتون برای ارسال دستوربه‌طور کلی پارامتر‌هایی که می‌توان با استفاده از local.cmdاجرا کرد به ترتیت به‌صورت زیر است:پارامتر · tgt : لیست ماشین‌های که قرار است دستورات بر روی آن‌ها اعمال شود.پارامتر · fun : لیستی از دستورات که می‌خواهیم بر روی ماشین‌ها اجرا شود.پارامتر · arg : لیستی از آرگومان‌هایی که برای اجرای دستورات پارامتر funنیاز است. لازم به ذکر است که طول این لیست باید متناظر با پارامتر‌ fun باشد.پارامتر · timeout : تعداد ثانیه‌هایی که بعد از آخرین minion منتظر می‌ماند.پارامتر · expr_form : نشان دهنده‌ی نوع معرفی در پارامتر tgt است.پارامتر · ret : نوع تابع بازگرداننده ای که برای دستورات می‌تواند مورد استفاده قرار گیرد.پارامتر · kwarg : یک dictionary همراه با لغات کلیدی برای توابع.مقداری که تابع local.cmd بر می‌گرداند یک dictionary است که کلید آن نام minion و مقدار متناظر با آن، داده های برگردانده شده از اجرای دستور است.یکی از مشکلات قطعه کد ‏2‑12 وجود timeoutو بلاکینگ بودن ساختار آن است. برای حل این مشکل می‌توان مطابق ... دستورات را به‌صورت غیر متقارن فرستاد تا روند اجرای برنامه برای انجام دستور متوقف نشود. پارامتر‌های این روش نیز همانند راهکار بلاکینگ است با این تفاوت که مقدار برگردانده شده از این تابع، شماره فعالیت زمان‌بندی شده برای اجرا است.local.cmd_async('*', 'test.sleep', [300])قطعه کد ‏2‑13 اجرای نامتقارن دستور بر روی ماشین‌ها در محیط پایتون2 مراجع[1]“Network-attached storage - Wikipedia, the free encyclopedia.” [Online]. Available: http://en.wikipedia.org/wiki/Network-attached_storage. [Accessed: 24-Jul-2013].https://teaching.iranmodares.com/teaching-index.php?metaword=%D9%85%D8%AD%D9%85%D8%AF+%D8%AD%D8%B3%DB%8C%D9%86+%D8%AC%D9%84%DB%8C%D9%84%DB%8C

امکانات اضافه شده در جاوا 8

محمد حسین جلیلی — Thu, 17 Nov 2022 00:40:03 +0330
1 امکانات جدید در زبان (language) جاوا1-1قابلیت Lambdas و رابط کاربردیقابلیت Lambdas بزرگترین تغییر در جاوا 8 است. این قابلیت به ما اجازه میدهد تا توابع را بصورت یک آرگومان متود (با ارسال به یک تابع) یا کد را بصورت داده ببینیم. در زیر مثالهای استفاده از این قابلیت را میبینیم.مثال 1:Arrays.asList( "a", "b", "d" ).forEach( e -> System.out.println( e ) );مثال 2:Arrays.asList( "a", "b", "d" ).forEach( ( String e ) -> System.out.println( e ) );مثال 3:Arrays.asList( "a", "b", "d" ).forEach( e -> {System.out.print( e );System.out.print( e );} );مثال 4:String separator = ","Arrays.asList( "a", "b", "d" ).forEach(( String e ) -> System.out.print( e + separator ) );مثال 5:final String separator = ","Arrays.asList( "a", "b", "d" ).forEach(( String e ) -> System.out.print( e + separator ) );مثال 6:Arrays.asList( "a", "b", "d" ).sort( ( e1, e2 ) -> e1.compareTo( e2 ) );مثال 7:Arrays.asList( "a", "b", "d" ).sort( ( e1, e2 ) -> {int result = e1.compareTo( e2 );return result;} );1-2 تغییر Interface پیشفرض یا متودهای staticجاوا 8 در extend کردن از interfaceدو مفهوم جدید تعریف کرده است: متودهای default و static. متودهای default امکان اضافه کردن متودهای جدید در interface های موجود را بدون شکستن سازگاری باینری با کدهای نوشته شده برای ورژنهای قدیمی تر آن interfaceها را می دهد.تفاوت بین متودهای default و متودهای abstractاین است که متودهای abstract نیازمند پیاده سازی شدن هستند اما متودهای default نه. در ادامه مثالی در این رابطه را میبینیم:private interface Defaulable {// Interfaces now allow default methods, the implementer may or// may not implement (override) them.default String notRequired() {return "Default implementation"}}private static class DefaultableImpl implements Defaulable {}private static class OverridableImpl implements Defaulable {@Overridepublic String notRequired() {return "Overridden implementation"}}رابط Defaulable یک متود defaultبه نام notRequired با استفاده از کلمه کلیدی default تعریف میکنیم. کلاس DefaultableImplرابط Defaulable را بدون overrideکردن متود default پیاده سازی میکند. اما کلاس OverridableImpl متود defaultرا override میکند.امکان جذاب دیگر در جاوا 8 این است که در interfaceمیتوان متودهای static را تعریف کرد. مثال زیر را ببنید:private interface DefaulableFactory {// Interfaces now allow static methodsstatic Defaulable create( Supplier< Defaulable > supplier ) {return supplier.get();}}حالا در متود main زیر نحوه استفاده از آنرا میبینیم.public static void main( String[] args ) {Defaulable defaulable = DefaulableFactory.create( DefaultableImpl::new );System.out.println( defaulable.notRequired() );defaulable = DefaulableFactory.create( OverridableImpl::new );System.out.println( defaulable.notRequired() );}و خروجی console:Default implementationOverridden implementation1-3بررسی Reference های متوداین قابلیت برای اشاره مستقیم به متودها یا سازندهای کلاسها یا آبجکتهای(نمونه های) جاوا استفاده میشود. Reference های متود با پیوستگی به Lambdas نمای زبان را فشرده و خلاصه میکند.در مثال زیر ابتدا کلاس کار را تعریف میکنیم و سپس نحوه استفاده از این قابلیت را روی آن نمایش میدهیم.public static class Car {public static Car create( final Supplier< Car > supplier ) {return supplier.get();}public static void collide( final Car car ) {System.out.println( "Collided " + car.toString() );}public void follow( final Car another ) {System.out.println( "Following the " + another.toString() );}public void repair() {System.out.println( "Repaired " + this.toString() );}}نوع اول reference های متود، referenceسازنده بصورت Class::new یا برای داده های عمومی Class::newاست. دقت کنید که سازنده آرگومانی ندارد.final Car car = Car.create( Car::new );final List< Car > cars = Arrays.asList( car );نوع دوم referenceهای متود، reference متود staticبصورت Class::static_methodاست. دقت کنید که متود دقیقا یک پارامتر از نوع Carدریافت میکند.cars.forEach( Car::collide );نوع سوم referenceهای متود، reference به متود یک آبجکت مشخص شده با نوع بصورت Class::method است. دقت کنید که توسط متود پارامتری دریافت نمیشود.cars.forEach( Car::repair );در نهایت نوع چهارم refrenceبه متود نمونه کلاس خاص نمونه بصورت instance::method است.دقت کنید که متود دقیقا یک پارامتر از نوع Car می پذیرد.final Car police = Car.create( Car::new );cars.forEach( police::follow );1-4 جایگزینی annotationهااز جاوا 5 پشتیبانی از annotationها معرفی شد، این امکان بسیار مشهور شد و بصورت گسترده استفاده شد. به هر حال یکی از محدودیت های استفاده از annotationدر واقع این است که نمیتوان بیش از یکی را در یک مکان تعریف کرد. جاوا 8 این قانون را شکسته و جایگزینی annotationها را معرفی کرده است. این امکان اجازه میدهد تا annotationچندین بار در همان مکان تعریف شده تکرار شود.جایگزینی annotationها با استفاده از @Repeatable annotationانجام میشود. در ادامه مثالی از آنرا میبینیم:package com.javacodegeeks.java8.repeatable.annotations;import java.lang.annotation.ElementType;import java.lang.annotation.Repeatable;import java.lang.annotation.Retention;import java.lang.annotation.RetentionPolicy;import java.lang.annotation.Target;public class RepeatingAnnotations {@Target( ElementType.TYPE )@Retention( RetentionPolicy.RUNTIME )public @interface Filters {Filter[] value();}@Target( ElementType.TYPE )@Retention( RetentionPolicy.RUNTIME )@Repeatable( Filters.class )public @interface Filter {String value();};@Filter( "filter1" )@Filter( "filter2" )public interface Filterable {}public static void main(String[] args) {for( Filter filter: Filterable.class.getAnnotationsByType( Filter.class ) ) {System.out.println( filter.value() );}}}خروجی برنامه بشکل زیر است:filter1filter22 امکانات جدید در کامپایلر جاوا2-1 نام پارامترهابرای سالها توسعه دهندگان جاوا راههای متفاوتی را برای نگهداشتن نام پارامترهای متود در بایت کد جاوا و آنها را در زمان اجرا ایجاد میکردند (برای مثال Paranamer library). در نهایت جاوا 8 به این نیاز پاسخ داد و امکانی با استفاده از Reflection API و متود Parameter.getName()و بایت کد با استفاده از کامپایلر javacبا آرگومان –parameters ایجاد کرد.package com.javacodegeeks.java8.parameter.names;import java.lang.reflect.Method;import java.lang.reflect.Parameter;public class ParameterNames {public static void main(String[] args) throws Exception {Method method = ParameterNames.class.getMethod( "main", String[].class );for( final Parameter parameter: method.getParameters() ) {System.out.println( "Parameter: " + parameter.getName() );}}}اگر این کلاس را بدون استفاده از آرگومان –parametersکامپایل و اجرا کنید، خروجی زیر را خواهید دید:Parameter: arg0اما با آرگومان –parametersخواهید دید:Parameter: args3 امکانات جدید در کتابخانه های جاوا3-1 بررسی Stream هابه تازگی Stream API(java.util.stream) به جاوا اضافه شده است. Stream API پردازشهای روی collectionsها را بصورت قابل توجه ای ساده میکند (البته تنها به collectionsمحدود نمیشود).اینجانب یک بررسی ساده روی سورس کدهای مربوط به Stream ها انجام دادم. دیدم که Stream یک interface است و در نتیجه برای آن کدی نوشته نشده است و در عوض تعداد زیادی از کلاسها این interface را implement کرده اند. در نتیجه هر کلاس یا Collection با استفاده از متودهای درون خود اینکار را انجام داده است. پس Stream در صورتی که بصورت parallel استفاده نشود، هیچ تاثیر منفی یا مثبتی روی کارایی و مصرف حافظه کدها ندارد و تنها کد نویسی را راحت میکند.با یک مثال ساده کار را شروع میکنیم.public class Streams {private enum Status {OPEN, CLOSED};private static final class Task {private final Status status;private final Integer points;Task( final Status status, final Integer points ) {this.status = status;this.points = points;}public Integer getPoints() {return points;}public Status getStatus() {return status;}@Overridepublic String toString() {return String.format( "[%s, %d]", status, points );}}}اکنون از کلاس taskیک مجموعه میسازیم. حالا می خواهیم با استفاده از Stream مجموعه pointهای مربوط به taskهای در حالت OPEN را محاسبه کنیم.// Calculate total points of all active tasks using sum()final long totalPointsOfOpenTasks = tasks.stream().filter( task -> task.getStatus() == Status.OPEN ).mapToInt( Task::getPoints ).sum();System.out.println( "Total points: " + totalPointsOfOpenTasks );و خروجی بصورت زیر است:Total points: 18حال می خواهیم مجموع pointهای تمام task ها را بصورت موازی (parallel) محاسبه کنیم.// Calculate total points of all tasksfinal double totalPoints = tasks.stream().parallel().map( task -> task.getPoints() ) // or map( Task::getPoints ).reduce( 0, Integer::sum );System.out.println( "Total points (all tasks): " + totalPoints );و خروجی بصورت زیر است:Total points: 26حال میخواهیم taskها را به توجه به OPENیا CLOSE بودنشان دسته بندی کنیم.// Group tasks by their statusfinal Map< Status, List< Task > > map = tasks.stream().collect( Collectors.groupingBy( Task::getStatus ) );System.out.println( map );و خروجی بصورت زیر است:{CLOSED=[[CLOSED, 8]], OPEN=[[OPEN, 5], [OPEN, 13]]}حال میخواهیم درصد وزنی هر taskرا نسبت به کل taskها بر روی pointهای آن محاسبه کنیم.// Calculate the weight of each tasks (as percent of total points)final Collection< String > result = tasks.stream() // Stream< String >.mapToInt( Task::getPoints ) // IntStream.asLongStream() // LongStream.mapToDouble( points -> points / totalPoints ) // DoubleStream.boxed() // Stream< Double >.mapToLong( weigth -> ( long )( weigth * 100 ) ) // LongStream.mapToObj( percentage -> percentage + "%" ) // Stream< String>.collect( Collectors.toList() ); // List< String >System.out.println( result );و خروجی بصورت زیر است:[19%, 50%, 30%]در ادامه مثالی می آوریم که از Stream API در collectionsاستفاده نمیشود و در کار با فایل استفاده کرده ایم.final Path path = new File( filename ).toPath();try( Stream< String > lines = Files.lines( path, StandardCharsets.UTF_8 ) ) {lines.( () -> System.out.println("Done!") ).forEach( System.out::println );}کد بالا تمام خطهای فایل را در خروجی چاپ میکند و در انتها عبارت "Done!" را چاپ میکند.3-2 موتور جاوا اسکریپت Nashornجاوا 8 امکان توسعه و اجرای برنامه های جاوا اسکریپ در JVM را از طریق موتور جاوا اسکریپت Nashorn فراهم کرده است. موتور جاوا اسکریپت Nashorn تنها پیاده سازی دیگری از javas.script.ScriptEngine است و همان مجموعه قوانین پیروی میکند که اجازه قابلیت همکاری جاوا و جاوا اسکریپت را میدهد. در اینجا یک مثال کوچک را میبینیم.ScriptEngineManager manager = new ScriptEngineManager();ScriptEngine engine = manager.getEngineByName( "JavaScript" );System.out.println( engine.getClass().getName() );System.out.println( "Result:" + engine.eval( "function f() { return 1; }; f() + 1;" ) );و خروجی بصورت زیر است:jdk.nashorn.api.scripting.NashornScriptEngineResult: 23-3 بررسی Base64سرانجام پشتیبانی از کدگزاری Base64در کتابخانه های استاندارد جاوا قرار گرفت. در ادامه با مثالی نحوه استفاده از آنرا نمایش میدهیم.package com.javacodegeeks.java8.base64;import java.nio.charset.StandardCharsets;import java.util.Base64;public class Base64s {public static void main(String[] args) {final String text = "Base64 finally in Java 8!"final String encoded = Base64.getEncoder().encodeToString( text.getBytes( StandardCharsets.UTF_8 ) );System.out.println( encoded );final String decoded = new String(Base64.getDecoder().decode( encoded ),StandardCharsets.UTF_8 );System.out.println( decoded );}}و خروجی بصورت زیر است:QmFzZTY0IGZpbmFsbHkgaW4gSmF2YSA4IQ==Base64 finally in Java 8!همچنین انواع دیگر از کدگزاری مخصوص URLو MIME نیز توسط همین کلاس پشتیبانی میشود.3-4 آرایه های موازیجاوا 8 تعداد بسیار زیادی از متودها را برای پردازش موازی آرایه ها اضافه کرده است. مسلما یکی از مهمترین آنها parallelSort()است که میتواند به میزان قابل توجه ای از طریق مرتب سازی در ماشینهای چند هسته ای سرعت را بالا ببرد. مثال کوچکی که در ادامه می آید متودهای جدید خانواده parallelXxxرا در عمل اثبات میکند.package com.javacodegeeks.java8.parallel.arrays;import java.util.Arrays;import java.util.concurrent.ThreadLocalRandom;public class ParallelArrays {public static void main( String[] args ) {long[] arrayOfLong = new long [ 20000 ];Arrays.parallelSetAll( arrayOfLong,index -> ThreadLocalRandom.current().nextInt( 1000000 ) );Arrays.stream( arrayOfLong ).limit( 10 ).forEach(i -> System.out.print( i + " " ) );System.out.println();Arrays.parallelSort( arrayOfLong );Arrays.stream( arrayOfLong ).limit( 10 ).forEach(i -> System.out.print( i + " " ) );System.out.println();}}از طریق کد کوچکی با استفاده از متود parallelSetAllاستفاده میکند تا آرایه ای را با 20000 مقدار تصادفی پر کند. سپس با استفاده از parallelSortآنها را مرتب میکند و سپس ده مقدار کوچکتر آنرا چاپ میکند. خروجی مشابه زیر است:Unsorted: 591217 891976 443951 424479 766825 351964 242997 642839 119108 552378Sorted: 39 220 263 268 325 607 655 678 723 7934 مراجع[1] http://www.javacodegeeks.com/2014/05/java-8-features-tutorial.html.[2] http://www.oracle.com/technetwork/java/javase/8-whats-new-2157071.html[3] http://docs.oracle.com/javase/tutorial/[4]http://blog.arungupta.me/2014/03/wildfly8-jdk8-netbeans8-javaee7-excellent-combo-enterprise-java/[5] http://winterbe.com/posts/2014/03/16/java-8-tutorial/https://teaching.iranmodares.com/teaching-index.php?metaword=%D9%85%D8%AD%D9%85%D8%AF+%D8%AD%D8%B3%DB%8C%D9%86+%D8%AC%D9%84%DB%8C%D9%84%DB%8C

راه اندازی و پیکربندی پرینتر سرور paper cut

محمد حسین جلیلی — Wed, 16 Nov 2022 23:50:26 +0330
1 معرفی نرم‌افزار papercutنرم‌افزاری قدرتمند همراه با امکانات بسیار در جهت مدیریت پرینتر‌های موجود در سازمان. نرم‌افزار paper cut در دو حوزه‌ی متفاوت موجود است که در این مستند PapercutNG را بررسی خواهد شد.این نرم‌افزار در شبکه نقش یک پرینتر سرور را بر عهده می‌گیرد که با استفاده از آن می‌توان سیاست‌های اتخاذ شده‌ی سازمان را بر روی پرینترها را پیاده سازی نمود. برخی از قابلیت‌های این نرم افزار عبارتند از:· بررسی و کنترل پرینتر‌های خارج از کنترل· اختصاص پرینتر‌ها به کاربران· بررسی این که چه کسی، چه چیزی را پرینت گرفته است· سهمیه بندی و یا بودجه بندی پرینترها· امکان استفاده در دستگاه‌های موبایلدر این مستند هدف آموزشِ نصب papercut و پیکربندی آن در جهت مدیریت پرینترها به منظور ایجاد کنترل دسترسی به پرینتر‌ها است این گونه که یک کاربر خاص بتواند پرینتر‌های خاصی را فقط مشاهده نماید.سیستم عاملی که در این مستند به عنوان میزبان papercut انتخاب شده است ویندوز ۷ است، البته این نرم‌افزار امکان نصب بر روی لینوکس را هم دارد.1 نصب papercutدر ابتدا پیشنهاد می‌شود که پرینتر‌های موجود در سازمان را بر روی ویندوز ۷ میزبان با استفاده از درایور‌های به روز شده‌ی آن‌ها نصب کنید بعد از آن شروع به نصب Papercut کنید، البته در صورتی که بعد از نصب Papercut هم پرینتر‌ها را اضافه کنید مشکلی به وجود نخواهد آمد.بعد از دانلود نرم‌افزار شروع به نصب آن خواهیم کرد.با توجه به این که ممکن است در نسخه‌های متفاوت نحوه‌ی کرک کردن متفاوت باشد در این مستند نحوه‌ی کرک کردن نرم‌افزار اموزش داده نخواهد شد.اولین قدم در نصب این نرم افزار توافق نامه‌ای است که می‌توانید در شکل ‏2‑1 مشاهده کنیدشکل ‏2‑1 توافق نامهدر قدم بعدی برای شما یک سری اطلاعاتی را نمایش خواهد داد. شکل ‏2‑2شکل ‏2‑2 اطلاعات تکمیلیدر مرحله‌ی بعدی از شما می‌خواهد که محل نصب نرم‌افزار را مشخص کنید. شکل ‏2‑3شکل ‏2‑3 محل نصبدر قسمت بعد، می‌توانید مورد استفاده‌ی سرور را انتخاب نمائید که در این قسمت گزینه‌ی primary serve را انتخاب می‌نمائیم . شکل ‏2‑4شکل ‏2‑4 مورد استفاده‌ی سروردر ادامه از شما می‌خواهد که آیا می‌تواند بر روی desktop ایجاد shortcut کند، که با توجه به تصمیم شما این کار را انجام خواهد داد. شکل ‏2‑5شکل ‏2‑5 ایجاد ایکون صفحه‌ی نمایشنمایش اطلاعات نهایی برای نصب نرم‌افزار. شکل ‏2‑6شکل ‏2‑6 اطلاعات نهاییبعد از نصب نرم‌افزار می‌توانید به پورت ۹۱۹۱ سرور از طریق browser متصل شوید و آن را پیکربندی نمائید.بعد از اتمام نصب از شما می‌خواهد که کاربر admin را ایجاد کنید. شکل ‏2‑7شکل ‏2‑7 ایجاد حساب کاربری adminدر این قسمت شما می‌توانید نوع سازمان خود را انتخاب کنید. شکل ‏2‑9شکل ‏2‑8 انتخاب قلمرو سازماندر قسمت بعدی شما می‌توانید برای استفاده از پرینتر‌ها هزینه تعیین کنید.شکل ‏2‑9شکل ‏2‑9 تعیین میزان هزینهدر قسمت بعدی شما می‌توانید کاربران موجود بر روی سیستم را به papercutمعرفی نمائید و به عنوان کاربران papercut به سیستم اضافه نمائید. شکل ‏2‑10شکل ‏2‑10 افزودن کاربراندر قسمت بعد به شما پیکربندی‌های موجود را نمایش می‌دهد و از شما می‌خواهد که آن‌ها را تایید نمائید. شکل ‏2‑11شکل ‏2‑11 نمایش نهایی اطلاعاتو در انتها از شما می‌پرسد که برخی از اطلاعات را با آن‌ها به اشتراک گذارید که توصیه می‌شود این کار را انجام ندهید برای این کار تیک گزینه‌ی موجود را بردارید شکل ‏2‑12شکل ‏2‑12 تکمیل پیکربندی2 پیکربندی نرم‌افزاربعد از ورود به نرم افزار در اولین صفحه می‌توانید اطلاعات مربوط به پرینترها و کاربران و ... را مشاهده نمائید. شکل ‏3‑1شکل ‏3‑1 نمایش اطلاعاتهمچنین برای پیکربندی قسمت‌های مختلف سرور می‌توانید از طریق نوار بار نشان داد ه شده در شکل ‏3‑2 انجام داد.شکل ‏3‑2 نوار پیکربندیدر ادامه برخی از پیکربندی‌های مورد نیاز نرم‌افزار را بررسی خواهیم کرد.2-1 تغییر logo در نرم‌افزاردر این قسمت می‌خواهیم با نحوه‌ی تغییر logo در نرم‌افزار آشنا شویم.برای تغییر logo در نرم‌افزار وارد قسمت options (شکل ‏3‑5 تغییر لوگو ) شده و در قسمت‌ client software (شکل ‏3‑3 تغییر لوگو client) می‌توان logo کلاینت را تغییر داد و همچنین در قسمت branding (شکل ‏3‑4 تغییر لوگو) قسمت‌های دیگر نرم‌افزار را تغییر داد.شکل ‏3‑3 optionsشکل ‏3‑4 تغییر لوگو clientشکل ‏3‑5 تغییر لوگوبه عنوان مثال بعد از تغییر logo صفحه‌ی ورود مانند شکل ‏3‑6 خواهد شد.شکل ‏3‑6 تغییر لوگو صفحه‌ی ورود2-2 اضافه کردن printerنحوه‌ی اضافه کردن پرینتر این‌ گونه است که بعد از افزودن printer بر روی میزبان سرور، آن printer در لیست پرینتر‌های موجود (شکل ‏3‑7 ) نمایش داده می‌شود. می‌توانید برای آموزش نحوه‌ی اضافه کردن printerبه مستند Add printer in windows and linux مراجعه نمائید.شکل ‏3‑7 لیست پرینتر‌هانکته) بعد از افزودن printer به سیستم در صورتی که پرینتر جدید به لیست pritnterها (شکل ‏3‑7) اضافه نشد سیستم را restart کنید تا این که این کار انجام شود.شکل ‏3‑8 افزودن پرینتر2-3 اضافه کردن کاربران گروه‌های کاربری و دسترسی‌هامدیریت کاربران در این نرم‌افزار می‌تواند توسط خود سیستم به صورت localباشد یا این که توسط active directoryصورت بگیرد. البته شما می‌توانید، یک batch بنویسید که عمل افزودن کاربران را به این نرم افزار انجام دهد که این مبحث خارج از محدوده‌ی این مستند است.در صورتی که قصد دارید از Active directory استفاده نمائید در ابتدا باید سیستم را به دامین joine کنید و بعد در نرم‌افزار کاربران را sync کنید. نحوه‌ی joine کردن کامپیوتر به active directory خارج از محدوده‌ی این مستند است. اما در صورتی که می‌‌خواهید از مدیریت کاربران به صورت local استفاده نمائید کافیست که کاربران را به سیستم اضافه کنید و در نرم افزار کاربران را sync کنید.در ابتدا برای مشاهده‌ی کاربران تعریف شده در نرم‌افزار وارد ناحیه‌ی users شوید (شکل ‏3‑9 ) و لیست کاربران موجود در سیستم را مشاهده نمائید، همچنین برای مشاهده‌ی گروه‌های موجود در نرم افزار می‌توانید وارد ناحیه‌ی groups شوید و لیست گروه‌های تعریف شده در نرم‌افزار را مشاهده نمائید.شکل ‏3‑9مشاهده‌ی لیست کاربرانبعد از افزودن کاربر یا گروه جدید در سرور نیاز است که در نرم‌افزار عمل sync را هم انجام دهید، برای انجام عمل sync وارد ناحیه‌ی options شده و در تب user/group sync می‌توانید محل sync شدن را انتخاب نمائید، به عنوان مثال اگر که سرور شما به دامین active directory یا LDAP متصل شده است نیاز است که گزینه‌ی مربوطه را انتخاب کنید و همچنین در صورتی که قصد دارید کاربران محلی را همگام کنید در این زمان windows standardرا انتخاب نمائید. شکل ‏3‑10شکل ‏3‑10 همگام کردن کاربرانهمچنین در صورتی که قصد دارید کاربران گروه خاصی را از روی سیستم به این نرم افزار اضافه نمائید می‌توانید مانند شکل ‏3‑11 گزینه‌ی Import users from selected groups انتخاب نمائید. و گروه مورد نظر را انتخاب کنید.شکل ‏3‑11 اتنخاب کاربران گروه خاصبعد از انتخاب محل به روز رسانی کاربران انتهای قسمت sync بر روی synchronize now کلیک کنید. شکل ‏3‑12شکل ‏3‑12 sync now2-4 مدیریت دسترسی printerها میان کاربراندر جهت سیاست‌های سازمان و ایجاد دسترسی‌های متفاوت می‌توانید دسترسی به printer را برای کاربران محدود کنید.به عنوان مثال کاربری خاص بتواند فقط از یک printerخاص استفاده کند و یا این که مدیر سازمان به تمام printerها دسترسی داشته باشد. برای این کار باید در ابتدا کاربر و یا گروه‌های کاربری متفاوتی را تعریف نمود و بعد دسترسی printerها را بر روی گروه‌های کاربری و یا کاربر مورد نظر اعمال کرد.در ادامه یک سناریو را پیاده سازی خواهیم کرد2-4-1 سناریو کنترل دسترسی کاربراندر ابتدا فرض کنیم که سازمان ما از چندین طبقه تشکیل شده است و این که در هر طبقه یک عدد printer وجود دارد، حال قصد داریم نرم‌افزار papercut را به نحوی پیکربندی کنیم که کاربران هر طبقه بتوانند به پرینتر همان طبقه دسترسی داشته باشند این گونه که پرسنل هر طبقه با وارد کردن یک حساب کاربری فقط به پرینتر طبقه‌ی خودشان دسترسی داشته باشند.برای این منظور در ابتدا نیاز است که گروهای کاربری ایجاد نماییم و کاربران مورد نظر را به گروه‌های مورد نظر اضافه نماییم و در انتها دسترسی پرینترها را محدود به گروه‌های مورد نظر کنیم.در ابتدا نیاز است که در سرور گروه ایجاد کنیم، برای این کار در سرور وارد manage کامپیوتر شده و مانند شکل ‏3‑13 عمل کنید.شکل ‏3‑13 managment consolدر این زمان وارد کنسول مدیریتی شده و در قسمت local users and groups شده در پوشه‌ی groups وارد شده و در ناحیه‌ی groups کلیک راست کرده و new group را انتخاب کنید. شکل ‏3‑14شکل ‏3‑14ایجاد گروه کاریبعد از ظاهر شدن صفحه‌ی ایجاد گروه، نامی را برای گروه تعریف کرده و اگر نیاز به توضیحات دارد در قسمت description وارد کنید و همچنین در صورتی که قصد دارید کاربر خاصی را به ان اضافه کنید می‌توانید بر روی Add کلیک کنید. شکل ‏3‑15شکل ‏3‑15 افزودن گروههمچنین برای این که کاربر جدیدی ایجاد کنید در قسمت Local users and groupsوارد شده و new userرا انتخاب کنید. شکل ‏3‑16شکل ‏3‑16 ایجاد کاربر جدیددر پنجره‌ی ظاهر شده مشخصات کاربر را وارد کرده و در صورت نیاز برای آن کلمه‌ی عبوری را تعیین کنید و بر روی create کلیک کنید. شکل ‏3‑17شکل ‏3‑17 افزودن کاربربرای این که یک کاربر را به یک گروه خاص اضافه کنید و یا این که ببینید، کاربر در چه گروه‌هایی عضو هستند شما می‌‌توانید بر روی نام کاربر کلیک راست کرده و بر روی propertiesکلیک کنید. شکل ‏3‑18شکل ‏3‑18 بررسی گروه های کاربردر پنجره‌ی ظاهر شده وارد تب member ofشده(شکل ‏3‑19 ) و لیست گروه‌هایی که کاربر عضو آن‌ها است را مشاهده نمائید.همچنین می‌توانید کاربر را از گروهی حذف و یا به گروهی اضافه کنید.شکل ‏3‑19 اطلاعات کاربربعد از آن که کاربران را ایجاد و به گروه‌های مورد نظر اضافه کردید در نرم‌افزار باید عمل syncشدن انجام گیرد.برای این کار وارد کنسول مدیریتی نرم‌افزار papercutشده و در قسمت optionsدر تب user/group syncبر روی synchronize nowکلیک کنید. شکل ‏3‑21شکل ‏3‑20 syncکردن کاربران و گروه‌هاشکل ‏3‑21 syncبعد از انجام عمل sync در قسمت groups وارد شده و از گروه‌های موجود گروه‌هایی را که قصد دارید به نرم‌افزار اضافه کنید. را انتخاب نمائید. برای این کار وارد قسمت groupsشوید. شکل ‏3‑22شکل ‏3‑22 افزودن گروهبعد از syncشدن می‌توانید در قسمت groupsبر روی add/remove groupsکلیک کنید و در صفحه‌ی جدید گروهای مورد نظر خود را اضافه کنید. شکل ‏3‑23شکل ‏3‑23 انتخاب گروهبعد از این که گروه‌ها را هم در نرم‌افزار اضافه کردیم نوبت به ایجاد دسترسی‌ها می‌رسد. برای این که یک پرینتر را محدود به یک گروه کنیم وارد پرینتر‌ها شده و پرینتر مورد نظر خود را انتخاب کنید و در قسمت filter & restrictionsدر قسمت Group Restrictionگروهی را انتخاب کنید که می‌خواهید به پرینتر دسترسی داشته باشد. شکل ‏3‑24شکل ‏3‑24 محدود کردن پرینترتا به این جا ما توانستیم که پرینتر‌ها را محدود کنیم به گروه‌ها و نحوه‌ی افزودن پرینتر و گروه و کاربر را آموختیم در ادامه می‌خواهیم نحوه‌ی استفاده از این نرم‌افزار در شبکه را آموزش دهیم و همچنین نکات دیگری را هم پیاده سازی کنیم.3 استفاده از نرم‌افزار در شبکهبعد از نصب نرم‌افزار و پیکربندی آن نیاز است که نرم‌افزار clientبر روی سیستم کاربران نصب شود تا با استفاده از آن شناسایی انجام شود.برای نصب نرم‌افزار client می‌توانید آدرس ip سرور را با فرم UNC در RUN اجرا کنید و بعد از وارد کردن نام کاربری و رمزعبور در پنجره‌ی ظاهر شده در پوشه‌ی PCClient وارد شده و با توجه به سیستم عامل خود نرم‌افزار client را نصب کنید. شکل ‏4‑1شکل ‏4‑1 دانلود فایل client3-1 نصب نرم‌افزار client در سیستم‌عامل ویندوزبرای نصب نرم‌افزار در ویندوز در ابتدا آدرس سرور را با فرم uncوارد کرده و وارد پوشه‌ی PCClientشوید. شکل ‏4‑2شکل ‏4‑2 دانلود clientبعد از وارد شدن به پوشه‌ی PCClient وارد پوشه‌ی win شده و client-local-install را نصب کنید. شکل ‏4‑3شکل ‏4‑3 نصب clientبعد از نصب نرم‌افزار از شما نام کاربری و رمز عبور را می‌خواهد که باید آن را وارد کنید.بعد از آن که نرم‌افزار client را نصب کردید نوبت به نصب پرینتر می‌رسد.برای نصب پرینتر در همان پنجره‌ی ظاهر شده از سرور بعد از وارد کردن آدرس سرور به فرم UNC می‌توانید بر روی پرینتر مورد نظر کلیلک راست کرده و گزینه‌ی connectرا انتخاب کنید. شکل ‏4‑4شکل ‏4‑4 اتصال به پرینتربعد از آن که به پرینتر متصل شدید می‌توانید از پرینتر استفاده کنید.3-2 نصب client در لینوکسبرای نصب client در لینوکس در ابتدا باید جاوا نسخه‌ی ۱۰ را نصب کنید.3-2-1 نصب جاوا در لینوکسدر ابتدا نرم‌افزار jdk v10 را از اینجا دانلود کنید.بعد از دانلود جاوا آن را به مسیر /usr/bin/java انتقال داده و با استفاده از فرمان tarاز حالت tar و zip خارج کرده مانند:tar xvfz jdk-10.0.2_linux-x64_bin.tar.gzفرمان ‏4‑1 نصب جاوابعد از این که از حالت tar خارج شد می‌توانید فایل tar.gz را پاک کنید و بعد از آن نیاز است که متغیر‌های javahomeرا تعریف کنیم.export JAVA_HOME="/usr/bin/java/jdk-10.0.”فرمان ‏4‑2 java homeبعد از این که متغیر javahome را تعریف کردید باید مسیر باینری جاوا را در PATHاضافه کنید.export PATH="$PATH:${JAVA_HOME}/bin"فرمان ‏4‑3 متغیر javaبعد از این که متغییرها را تعریف کردید نیاز است که آن‌ها را در فایل /etc/profile قرار دهید تا در تمام تمامی shell‌های دیگری که اجرا می‌شوند این متغییر برایشان تعریف شده باشد.بعد از این که جاوا را نصب کردید نوبت به این می‌رسد که کلاینت papercutرا نصب کنیم برای این کار در لینوکس در قسمت network مانند شکل ‏4‑5 ip سرور papercut را وارد کنید تا این که بتوانید فایل PCClientرا برای لینوکس از آنجا کپی کنیم.شکل ‏4‑5 اتصال در لینوکسبعد از ورود به سرور وارد دایرکتوری PCClient شده و دایرکتوریی linux را بر روی سیستم خود کپی کنید.بعد از آن که دایرکتوری linux را بر روی سیستم خود کپی کردید مسیر /usr/local/papercut/clientرا ایجاد کنید و تمامی محتوای داخل دایرکتوری linux را به /usr/local/papercut/client انتقال دهید. بعد از انتقال نوع فایل pc-client-linux.sh را به حالت اجرایی تبدیل کنید.chmod 755 ./pc-client-linux.shفرمان ‏4‑4 اجرایی کردن فایلبعد از این که فایل را به صورت اجرایی تبدیل کردید آن را اجرا کنید. فرمان ‏4‑5./pc-client-linux.shفرمان ‏4‑5 اجرای clientبعد از اجرای فایل pc-client-linux.shدر پنجره‌ی ظاهر شده نام کاربری و رمز عبور خود را وارد کنید.همچنین برای نصب پرینتر ب روی سیستم عامل لینوکس می‌تواند به مستند Add printer in windows and linuxمراجعه نمائید3-3 استفاده از پرینتر‌های سازمان بدون نرم‌افزار کلاینتدر صورتی که قصد دارید نرم‌افزار کلاینت را بر روی سیستم‌ کاربران نصب نکنید کافی است که دسترسی کاربران به پرینتر‌های موجود محدود کنید به عنوان نمونه دسترسی یک پرینتر را برای گروه‌های مختلف آزاد کنیم مانند شکل ‏4‑6 که پرینتر را برای گروه‌های floor3, floor4, floor5 مجاز قرار داده است.شکل ‏4‑6 تخصیص پرینتر به گروه‌های کاری دیگربعد از آن فقط کاربران عضو این گروه‌ها هستند که می‌توانند به پرینتر‌ متصل شوند.همچنین شما می‌توانید به گونه‌ی دیگری هم که در قسمت ‏3-4-1 گفته شد ایجاد محدودیت را برای کاربران اعمال کنیدhttps://teaching.iranmodares.com/teaching-index.php?metaword=%D9%85%D8%AD%D9%85%D8%AF+%D8%AD%D8%B3%DB%8C%D9%86+%D8%AC%D9%84%DB%8C%D9%84%DB%8C

آموزش RSS و نحوه‌ی استفاده از آن در جاوا

محمد حسین جلیلی — Sat, 12 Nov 2022 00:16:59 +0330
در این مستند به بررسی چند نوع از کتابخانه‌های RSS خوان در زبان برنامه‌نویسی جاوا خواهیم پرداخت.اینگونه می‌توان برداشت کرد که یکی از بهترین ابزار RSS خوان در زبان برنامه نویسی جاوا ابزار Rome به دلیل مستندات جامع و کامل، پشتیبانی از تمامی فرمت‌ها و همچنین وجود مثال‌های متعدد اشاره کرد که این ویژگی‌ها در دیگر ابزارهای این مستند وجود ندارد.1-1 منظور از RSS چیست؟کلمه RSS مخفف "Really Simple Syndication" است که به ‌اختصار به آن "Rich Site Summary" گفته می‌شود. RSS برای خواندن اطلاعات و محتویات یک صفحه وب بدون هیچ طراحی یا صفحه‌آرایی استفاده می‌شود. RSSها، توسط کدهای xml نوشته می‌شود. این نوع کدها، بسیار شبیه به کدهایhtml هستند اما با این تفاوت که فاقد طراحی و کدهای صفحه‌آرایی هستند. فایل ساخته‌شده با کدهای xml دارای همان پسوند xml هستند و به دلیل نداشتن هیچ چیدمان و طراحی، دارای حجم بسیار پایینی می‌باشند.1-2 مزایای استفاده از RSSنداشتن طراحی برای صفحات RSS سبب می‌شود تا سرعت شما در خواندن مطالب فرستاده‌شده در RSS بالا رود و مجبور نباشید تا برای لود شدن طراحی و گرافیک صفحات وب، هم اینترنت خود را مصرف کنید و هم‌زمانی را صرف لود شدن گرافیک صفحات نمایید. شما می‌توانید سایت‌ها و وبلاگ‌هایی که مطالب آن‌ها برای شما Feed است و نیاز دارید که مدام به آن‌ها سر بزنید و از به‌روزرسانی آن‌ها، آگاهی یابید، لیست کرده و به RSS خود بفرستید و بدون صرف وقت و اینترنت اضافه، از بروز رسانی آن‌ها مطلع گشته و از مطالب صفحات موردنظر آن‌ها استفاده نمایید.1-3 تفاوت RSS و Atomامروزه اکثر سایت‌ها بمنظور آسان‌سازی دسترسی کاربرانشان به آخرین اخبار از پروتکل‌های Syndication Feed استفاده می‌کنند. به همین خاطر سایت‌های خبری و وبلاگ‌ها به‌منظور ایجاد ارتباط بیشتر، صحیح‌تر و آسان‌تر با مخاطبینشان ملزم به استفاده از این پروتکل‌ها می‌باشند. در سواد عمومی جامعه عموماً Feed‌ها بانام RSS شناخته می‌شوند، درصورتی‌که RSS تنها یکی از دو نوع استاندارد تعریف‌شده هست، استاندارد دوم Atom نام دارد. Atom به یک جفت استاندارد وب اعمال می‌شود که مانند RSS یک‌زبان xml است و به‌عنوان پروتکلی برای Feedهای وب استفاده می‌شود.فرمت Atom به‌عنوان یک جایگزین برای RSS مطرح شد. بن تروت یکی از توسعه‌دهندگان این قالب، معتقد بود که RSS دارای محدودیت‌ها‌ و نقص‌هایی مانند عدم نوآوری به دلیل سازگاری با نسخه‌های قبلی و عدم وجود طرح‌های جدید است. به‌همین دلیل Atom به‌عنوان استاندارد پیشنهادی IETF در دسامبر 2005 تصویب و پروتکل آن در اکتبر 2007 منتشر شد.1-3-1 برخی از تفاوت‌های اصلی RSS و Atomتکنولوژی RSS دارای محبوبیت بیشتری است.اما Atom قدرت بیشتری داردتکنولوژی Atom استاندار IETF را پشتیبانی می‌کند.تکنولوژی RSS نسخه 2 مشکلات نسخه قبل را برطرف و قابلیت پشتیبانی از پادکست رو اضافه کرده است.تکنولوژی Atom کدهای HTML یا صدا و تصویر را باهم به نمایش در می‌آورد.تکنولوژی Atom تغییرات در محتوای فرستاده‌شده رو به کاربر اطلاع می‌دهد.1-4 استفاده از RSSتکنولوژی RSS به دو شكل ایفای نقش می‌كند: وقتی‌که خودتان اطلاعاتی دارید كه می‌خواهید منتشر كنید و در اختیار دیگران قرار دهید، كار نشر یا Syndication را انجام می‌دهد و زمانی كه بخواهید اطلاعاتی را به دست آورده و مورداستفاده قرار دهید، كار گردآوری یا Aggregation را بر عهده می‌گیرد. ما در این گزارش به نقش گردآوری RSS می‌پردازیم و این‌که چگونه یک بولتنی خبری درست كنید كه دیگران بتوانند خبرهای شما را بخوانند در این گزارش توضیح داده نمی‌شود.همان‌گونه که گفته شد هیچ‌كس نیاز ندارد هرروز تمام خبرهای دنیا را بخواند، بلكه هرکسی بسته به علاقه، شغل، یا وظیفه‌ای كه دارد فقط بعضی از خبرها را می‌خواند. برای این منظور به یك ابزار گردآوری احتیاج داریم كه بتواند به‌طور خودكار به سراغ سایت‌هایی برود كه به اشتراك آن‌ها درآمده‌ایم. ابزارهای گردآوری در بازار و اینترنت فراوان یافت می‌شود.در بخش بعدی انواع مختلف ابزارهای منبع باز را، برای زبان برنامه‌نویسی جاوا مورد بررسی قرار می‌دهیم.2 ابزارهای منبع باز2-1 ابزار Informaپروژه Informa یک کتابخانه RSS را بر اساس بستر جاوا فراهم می‌کند. برخی از امکانات این پروژه، نوشتن RSS، خواندن RSS، ذخیره‌سازی و جستجو می‌باشد.هدف از پروژه Informa این است که یک کتابخانه جمع‌آوری اخبار بر روی بستر جاوا ارائه دهد. این ایده توسط نویسندگان دو خبرخوان (HotSheet و Risotto) ایجاد شد. آن‌ها بخش‌های مشترک این دو برنامه را در یک کتابخانه باهم ترکیب کردند که می‌تواند توسط هر توسعه‌دهنده‌ای که نیاز به پاسخگویی به این مسائل در برنامه خود دارد مورد استفاده قرار گیرد. این پروژه از اکثر فرمت‌های RSS مانند (RSS 0.91, 1.0, 2.0 and Atom 0.3, 1.0) پشتیبانی می‌کند.جهت کسب اطلاعات بیشتر می‌توانید به این لینک مراجعه نمایید.2-1-1 مزایا1. تجزیه‌کننده[1] RSS2. تولیدRSS3. تجزیه‌کننده Atom4. کتابخانه جاوا5. پشتیبانی از اکثر نسخه‌های RSS و Atom6. سازگار با اکلیپس7. دارای JavaDoc8. جستجو درباره یک RSS خاص2-1-2 معایب1. در حال حاضر، Informa در حالت بتا قرار دارد اما بااین‌وجود کاملاً پایدار و قابل‌استفاده است.2. از سال 2007 تابه‌حال به‌روزرسانی نشده است.3. اطلاعات زیادی در اینترنت در مورد این ابزار وجود ندارد.2-2 کتابخانه SAXیک RSS خوان بسیار ساده که توانایی خواندن اRSSنسخه2 را دارا هست. این کتابخانه به‌صورت پیش‌فرض از جاوا 5 به بعد وجود دارد. برنامه ‏2‑2 و برنامه ‏2‑2public class RSSFeedReader {public static void read(String url, RSSFeedStore store) {try {SAXParserFactory spf = SAXParserFactory.newInstance();SAXParser saxParser = spf.newSAXParser();RSSFeedSaxHandler handler = new RSSFeedSaxHandler(store);saxParser.parse(url, handler);} catch (SAXException e) {e.printStackTrace();} catch (IOException e) {e.printStackTrace();} catch (ParserConfigurationException e) {e.printStackTrace();}}{برنامه ‏2‑1 نمونه کلاس ساده‌ArrayListRSSFeedStore feedStore = new ArrayListRSSFeedStore();RSSFeedReader.read("http://some.url.com/feed/", feedStore);ArrayList list = feedStore.getList();for (RSSItem RSSItem : list) {System.out.println("guid: " + RSSItem.getGuid());System.out.println("title: " + RSSItem.getTitle());System.out.println("description: " + RSSItem.getDescription());System.out.println("link: " + RSSItem.getLink());System.out.println("");}برنامه ‏2‑2 نمونه ای ساده از نحوه اجرا2-2-1 مزایا1. پیاده سازی بسیار آسان و ساده2. سهولت استفاده3. نیاز به هیچ کتابخانه خارجی از جاوا 5 به بعد ندارد.2-2-2 معایب1. عدم پشتیبانی کامل از RSS نسخه 2.2. از تجزیه کننده Atom پشتیبانی نمی‌کند.3. به دلیل سادگی امکان مانور کمتری دارد.4. اطلاعات بسیار کمی در اینترنت در مورد این کتابخانه وجود دارد..2-3 ابزار Romeابزار ROME یک چارچوب جاوا برای خوراک RSS و Atom است. این پروژه منبع باز و تحت لیسانس آپاچی 2.0 است.ابزار rome شامل مجموعه ای از تجزیه کننده‌ها و تولید کننده‌ها برای انواع مختلف Feed و همچنین مبدل‌ها برای تبدیل از یک فرمت به دیگری هست. تجزیه‌کننده‌ها می‌توانند با اشیاء[2] جاوا که مخصوص فرمت موردنظر شما می‌باشند کار کنند. این ابزار اکثر فرمت‌ها را پشتیانی می‌کند که این عمل به شما اجازه می‌دهد تا با داده‌ها بدون هیچ‌گونه ناراحتی در مورد نوع Feed ورودی یا خروجی کارکنید.جهت کسب اطلاعات بیشتر به این لینک مراجعه نمایید.2-3-1 مزایا1. راحتی در استفاده2. پیاده‌سازی آسان3. کامل بودن (تمامی نسخه‌ها را مدیریت می‌کند)4. نیاز به معماری خاصی ندارد.5. قدرتمند از این نظر که به ما اجازه می‌دهد به انواع Feedها بدون در نظر گرفتن فرمتشان به آن‌ها دسترسی پیدا کنیم.6. دارای مستندی جامع و کامل2-3-2 معایب:1. باوجود پیاده‌سازی ساده اما به‌سادگی کتابخانه SAX نیست.2-4 ابزار FeedParserابزار FeedParser یک تجزیه‌کننده RSS , Atom بر اساس زبان جاواست که از تمام نسخه‌های RSS مانند 0.93 ، 0.91، 0.92، 1.0 ، 2.0 و Atom نسخه 0.5 و دیگر نسخه‌ها (طبق گفته سازنده) پشتیبانی می‌کند.ابزار FeedParser یک API تجزیه‌کننده هست که توسط کوین برتون برای NewsMonster طراحی و به‌منظور ادامه توسعه به ASF اهدا شد.ابزار FeedParser با بسیاری دیگر پارسرهای RSS / Atom متفاوت است و تا حدودی شبیه SAXعمل می‌کند. با این تفاوت که به‌جای عناصر سطح پایین در API موجود در SAX، رویدادهای سطح بالاتری را روی اطلاعات Feed تجزیه می‌کند.جهت کسب اطلاعات بیشتر به این لینک مراجعه نمایید.2-4-1 مزایا1) شناسایی خودکار اکثر نسخه‌های RSS و Atom2) پشتیبانی از تمامی ماژول‌های محتوا مانند : and atom:summary xhtml:body, mod_content (RDF and inline), atom:content,3) پشتیبانی از Atom 1 به‌خوبی RSS 1 است.4) تجزیه‌کننده لینک HTML برای پیدا کردن همه لینک‌ها در یک فایل منبع HTML و توسعه آن‌ها به URL کامل.2-4-2 معایب1) طبق گفته سایت سازنده در صورت عدم کارکرد درست برنامه و یا عدم رضایت از آن می‌توانید از برنامه Rome استفاده نمایید.2-5 ابزار YarFrawابزار Yarfraw یک کتابخانه APIمنبع باز[3] برای کار با خوراک RSSاست. این مدل داده‌ای به توسعه‌دهندگان در تولید و خواندن RSSها کمک می‌کند. این API اکنون به‌طور کامل از RSS 2.0، RSS 1.0 و Atom 1.0 پشتیبانی می‌کند. تقریباً دیگر هیچ وب‌سایتی که بر روی RSS 0.9x تولیدشده باشد وجود ندارد، اما API قادر به خواندن Feedهای RSS 0.9x بدون هیچ مشکلی است زیرا RSS 2.0 باید با نسخه‌های قبلی سازگار باشد.با توجه به شکل ‏2‑1 هسته مدل Api Yarfraw شاید در ابتدا تصور کنید که این فرمت‌ها با یکدیگر ناسازگار هستند، اما واضح است که همه آن‌ها شامل یک مجموعه اطلاعات هستند. که عبارت‌اند از:لیستی از "Item" یا "Entry"، هر یک از موارد بالا و همچنین شامل برخی از متاداده‌های بیشتر و همچنین یک قسمت محتوای است که حاوی محتوای اصلی است.ازآنجایی‌که دقیقاً آن‌ها همان اطلاعاتی هستند که تنها در فرمت‌های مختلف هستند، به‌وضوح می‌توانیم همه آن‌ها را در یک مدل واحد بنویسیم و آن‌ها را به فرمت‌های دیگر تبدیل کنیم. کلاس داده‌های Yarfraw یک مدل یکپارچه ارائه می‌دهد که به‌اندازه کافی برای پوشش همه این فرمت‌ها بزرگ است. با این کار، فقط باید با یک مدل داده کارکنید و درعین‌حال از تمامی فرمت‌های مختلف نیز پشتیبانی می‌کند.جهت کسب اطلاعات بیشتر به این لینک مراجعه نمایید.شکل ‏2‑1 هسته مدل Api Yarfraw2-5-1 مزایا1) پشتیبانی از اکثر فرمت‌ها2) یکپارچه شدن فرمت‌های مختلف در یک مدل3) مستقل کردن بخش‌ها از یکدیگر4) دارای Javadoc5) مستندسازی به‌صورت خوب.2-5-2 معایب1) آخرین نسخه منتشرشده مربوط به سال 2008 است.2) عدم وجود مثال‌های متعدد در اینترنت2-6 برنامه Feedzeoبرنامه‌ای ساده و درعین‌حال قدرتمند تحت وب است که به زبان جاوا برای خواندن Feedهای RSS,Atom ایجاد و تحت مجوز GNU LPGLفعالیت می‌کند. این برنامه از دو بخش سرور و کلاینت تشکیل‌شده است. بخش سرور این برنامه به زبان جاوا و بخش کلاینت با Ajax وhtml نوشته‌شده است.نحوه عملکرد این برنامه به این صورت است که سروری که متصل به شبکه است Feedهای Atom و RSS دانلود و اجرا می‌کند به‌صورت فایل‌های data و html به کلاینت ارسال می‌کند.در شکل 2 و شکل 3 تصویری از برنامه را مشاهده می‌کنید.شکل 2 تصویری از برنامهشکل 3 تصویری از برنامهجهت کسب اطلاعات بیشتر به این لینک مراجعه نمایید.2-6-1 مزایا1) ساده و قدرتمند2) پرسرعت3) جدا بودن بخش‌های سمت سرور و کلاینت4) تغییر نحوه نمایش Feedها2-6-2 معایب1) عدم وجود Javadoc2) هم‌اکنون در نسخه بتا قرار دارد.3) آخرین نسخه برنامه مربوط به سال 2006 است.4) از تمامی نسخه‌های Atom و RSS پشتیبانی نمی‌کند.5) نبود مستندات کافی حتی در خود سایت سازندهhttps://teaching.iranmodares.com/teaching-index.php?metaword=%D9%85%D8%AD%D9%85%D8%AF+%D8%AD%D8%B3%DB%8C%D9%86+%D8%AC%D9%84%DB%8C%D9%84%DB%8C

مثال راه اندازی شبکه

محمد حسین جلیلی — Fri, 11 Nov 2022 01:01:15 +0330
آنچه که در این مستند گفته می‌شود مواردی کاربردی و ابتدایی در شبکه است که انتظار می‌رود در پس از گذارندن دوره‌های ابتدایی شبکه دانشجو بتواند انجام دهد.سرفصل‌هایی که شما در ادامه می‌خوانید تماماً کاربردی بوده و در زمان راه اندازی شبکه استفاده خواهد شد.آنچه که در این مستند بیان خواهد شد:آشنایی با نحوه‌ی VLAN بندی در سوئیچ‌های سیسکوآشنایی با VTP تنظیم پسوورد برای سوئیچ‌هاچگونگی تنظیم switch برای ssh و telnet زدن به آننحوه‌ی استفاده از TFTP SERVERآموزش چگونگی کابل زدن شبکه1 شبکه مجازی محلی Vlan بندی برای switchبعد از اتصال به سوئیج شما صفحه‌ای مانند زیر می‌بینید شکل ‏1‑1 establish work with switchشکل ‏1‑1 establish work with switchاز این به بعد شما برای فعال کردن سوئیچ در این مرحله باید فرمان زیر را وارد کنید تا این که switch از حالت غیر فعال به حالت فعال تغییر حالت بدهد. برنامه ‏1‑1 enableEnableبرنامه ‏1‑1 enableبعد از وارد کردن فرمان switch به حالت آماده باش در می‌آیدشکل ‏1‑2 فعال کردن switchنکته) در اکثر مواقع احتیاجی به وارد کردن فرمان به صورت کامل نیست به عنوان مثال اگر شما فرمان en را هم وارد میکردید switch فعال می‌شد .نکته) شما می‌توانید با زدن کلید Tab کلمه‌ی ناقص نوشته شده را کامل و همچنین option های موجود را در این مرحله مشاهده کنید و در زمانی که consol نتوانست تمام textها را نمایش دهد باید از کلید space یا enterاستفاده کنید تا ادامه خروجی را در صفحه مشاهده کنید.شما در این مرحله سوئیچ را فعال کرده و حالا سوئيچ آماده شده برای دریافت و اجرای دستورات.حالا شما بسته به نوع انتخابتان در نوع سوئیچ تعدادی پورت دارید که پورت ها هم بسته یه switch دارای تعدادی پورت fast و تعدادی پورت gig است.شما برای ایجاد vlan و قرار دادن پورت‌ها در یک vlan در ابتدا باید یک vlan به یک نام دلخواه ایجاد کنید بعد در مرحله بعدی یک سری از پورت‌های مورد نظر را به یکی از vlan ها اضافه کنید برای انجام این کار مانند زیر عمل کنید:برای ایجاد یک vlan در سوئیچ مطابق تصاویر زیر عمل کنید. برنامه ‏1‑2 add vlanEnableConfiguration terminalVlan 2(Id for vlan)Name test(name for vlan)برنامه ‏1‑2 add vlanشکل ‏1‑3 add vlanبعد از وارد کردن کد بالا شما یک vlan به switch اضافه کردید برای مشاهده vlan ها باید فرمان زیر را وارد کنید.نکته) برای اجرای این فرمان شما باید از مسیر جاری خارج شده و در مسیر config سوئیچ نباشبد یا از فرمان do استفاده کنید که در صورت استفاده از فرمان do شما دیگر از خاصیت auto complete نمی‌توانید استفاده کنید برنامه ‏1‑3 show vlanبرنامه ‏1‑4 show vlanShow vlanبرنامه ‏1‑3 show vlanORShow brife vlanبرنامه ‏1‑4 show vlanشکل ‏1‑4 نمایش vlanحالا شما می‌توانید vlanهای موجود را مشاهده کنیددر مرحله بعد می‌خواهیم که یک سری پورت را به vlan موجود (test) اضافه کنیمبرای این کار شما باید پورت یا پورت‌هایی را که می‌خواهید در یک vlan خواص قرار دهید به صورت انفرادی یا گروهی انتخاب کنید بعد یه vlan مورد نظر الحاق کنید.برای مثال من می‌خواهم پورت‌های Fa0/9 را به یک vlan با id ۲ یا نام test الحاق کنم.برای این کار فرمان‌های زیر را وارد می‌کنم برنامه. ‏1‑5 attach vlanEnableConf tInterface fastethernet 0/9Switchport access vlan 2(id vlan)برنامه ‏1‑5 attach vlan1-1 قرار دادن یک پورت به صورت trunkبرای این که یک پورت را به صورت trunk قرار دهیم باید مانند نمونه پایین کار را انجام دهیممن به عنوان مثال پورت‌های gig 0/1و gig 0/2 را به صورت trunk قرار دادمبرنامه ‏1‑6 trunkenConfiguration terminalInterface range gig0/1 - 2Switchport mod trunkSwitchport turnبرنامه ‏1‑6 trunkبرای مشاهده پورت‌های به صورت trunk ازفرمان زیر استفاده کنید برنامه ‏1‑7 show trunkenShow interface trunkبرنامه ‏1‑7 show trunk1-2 چگونه یک VLAN را حذف کنیمبرای اینکه یک vlan را حذف کنیم کافیست از فرمان زیر استفاده کنیم برنامه ‏1‑8 delete vlanenConf tNo vlan id(id of vlan)برنامه ‏1‑8 delete vlan2 آموزش VLAN Trunking Protocol (VTP)تکنولوژی Vtp به مدیر شبکه اجازه می‌دهد که vlanهای یک سوئیچ را بر روی دیگر سوئیچ‌های موجود در شبکه تحت یک دامنه یکسان copy کند.شرایط عضویت در VTPدامین:1. عضویت در یک دامین هم نام2. وجود لینک از نوع Trunkبین سوئیچ ها3. وجود حداقل یک سوئیچ در حالت Server2-1 حالت‌های VTPشما می‌توانید یک سوئیچ را به یکی از حالت‌های زیر config کنید :2-1-1 VTP Serverدر این حالت شما می‌توانید ایجاد کنید٬ توسعه دهید ٬ حذف کنید و دیگر پارامتر‌های config خاصی را انجام دهید به عنوان مثال version VTP برای دامنه VTPهای ورودی .سوئیچ Vtp serverها پخش می‌کنند ((vlan configuration))های خودشان را روی دیگر سوئیچ‌هایی با VTP domain یکسان و همچنین همزمان سازی می‌کنند vlan config خودشان را با سوئیچ‌هایی بر مبنای گیرنده اطلاعات vlan٬ روی لینک trunk .2-2 Vtp clientسوئیچ‌های Vtp client مانند VTP Server عمل می‌کند یعنی با دریافت به روز شده‌ی اطلاعاتِ vlan ها ٬ آ‌ن اطلاعات را روی trunk انتقال می‌دهد ولی شما نمی‌توانید که ایجاد کنید و یا حذف کنید و یا تغییر بدهید آن‌ها رابنابراین clientها بر اساس vtp serverها config شده‌اند2-3 VTP transparentسوئیچ‌های VTP Transparent که در این مود قرار گیرد ، میتواند Vlan Database خود را داشته باشد ولی به بقیه ارسال نمیکند ولی اطلاعات Vlan Database دریافتی را بر روی پورت های ترانک خود ارسال مینماید همچنین می‌تواند ‌آن‌ّها تغییر دهد .2-4 نحوی تنظیم VTPجهت تعیین نقش سوئیچ از دستور زیر استفاده می کنیم:برنامه ‏2‑1 ایجاد mode - برنامه ‏2‑2 ایجاد modeSwitch(config)#vtp mode clientبرنامه ‏2‑1ایجاد modeیاSwitch(config)#vtp mode serverبرنامه ‏2‑2ایجاد modeجهت مشخص کردن نام دامین از دستور زیر: برنامه ‏2‑3 نام دامنهنکته : اگر نام دامین خالی باشد مقداری که در اولین سوئیچ وارد می کنیم در تمام سوئیچ ها دیگر نیز وارد می شود.Switch(config)#vtp domain itproبرنامه ‏2‑3 نام دامنهپسورد گذاشتن:برنامه ‏2‑4 پسووردSwitch(config)#vtp password mypassبرنامه ‏2‑4 پسووردتعیین نسخه مورد استفاده: برنامه ‏2‑5 تعیین versionSwitch(config)#vtp version 2برنامه ‏2‑5 تعیین versionنمایش جزئیات: شکل ‏2‑1 نمایش جزئیاتشکل ‏2‑1نمایش جزئیات3 تنظیم پسوورد برای switchشما برای پسوورد گذاری در switch می‌توانید مراحل زیر را انجام دهید3-1 پسوورد گذاری برای consolبرای این که به consol رمز بدهید مانند زیر عمل کنید برنامه ‏2‑1 set pass for consolConf tLine consol 0Pass XXXXLoginبرنامه ‏2‑1 set pass for consol3-2 پسوورد گذاری برای زمانی که می‌خواهید login شویدبرای این کار کافی است که فرمان زیر را وارد کنید برنامه ‏2‑2 secret loginConf tEnabel secret xxxبرنامه ‏2‑2 secret login4 چگونگی تنظیم switch برای ssh و telnet زدن به آنبرای این که بتوانید با سوئیچ ارتباط بر قرار کنید باید مراحل زیر را انجام دهید4-1 نام دهی به یک سوئیچبرای این کار کافی است که از فرمان زیر استفاده کنید برنامه ‏3‑1 switchenConf tHostname xxxxxبرنامه ‏3‑1 switch4-2 نحوه‌ی ip دهی به سو‌پیچشما برای ip دهی به switch باید vlan خاصی را تعریف کنید و به ‌ان vlan آدرس بدهید مانند زیر َعمل کنید. برنامه ‏3‑2 set ipenConf tInterface vlan XIp add xxx.xxxx.xxxx.xx 255.255.255.000No shutdownبرنامه ‏3‑2 set ip4-3 تنظیم پسوورد برای vtyنکته ) وی تی وای پورت‌های مجازی می‌باشند که ما با استفاده از این پورت‌ها می‌توانیم به سوئیچ متصل شویم و می‌توانیم تعیین کنیم که کدام پورت با جه پروتکلی باشد.برنامه ‏3‑3 pass vtyenConf tLine vty 0 10Pass XXXLoginEndبرنامه ‏3‑3 pass vtyشما در حال حاضر می‌توانید به سوئیچ از طریق telnet متصل شوید.برای تنظیم سوئیچ که بتوان به آن ssh زد مانند زیر عمل کنید.4-4 تنظیم ip domainبرای تنظیم ip domain باید مانند زیر عمل کنید برنامه ‏3‑4 ip domainenConf tIp domain-name XXXXXXXXXX.XXXبرنامه ‏3‑4 ip domainنکته) شما باید به جای XXXXXXXXXX.XXX ها نام یک سایت را وارد کنید4-5 رمز گذاری برای اطلاعاتاز آنجا که ssh از نظر امنیت قابل اطمینان تر از telnet است شما باید اطلاعات رمز کرده برای این کار کافی است مانند زیر عمل کنید برنامه ‏3‑5crypto dataenConf tcrypto key generate rsaبرنامه ‏3‑5 crypto dataبعد از ورود فرمان بالا سوئیچ از شما پهنای باند را می‌خواهد که به صورت پیش فرض این مقدار ۵۱۲ است شما می‌توانید این مقدار را تغییر دهید مثلا به ۱۰۲۴ آن را تغییر دهید4-6 انتخاب نوع ارتباطبعد انجام مراحل بالا شما باید نوع ارتباط را انتخاب کنیدبرای این کار مانند زیر عمل کنید برنامه ‏3‑6 نوع اتصالenConf tLineTransport input sshبرنامه ‏3‑6 نوع اتصالدقت داشته باشید دیگر شما نمی‌توانید با telnet به SWITCH متصل شوید5 نحوه‌ی استفاده از TFTP SERVERشما از TFTPمی‌توانید برای ذخیره فایل‌های config استفاده کنید برای این کار شما احتیاج به یک نرم افزار یا یک سرور که سرویس TFTP را را دارا باشد دارید مانند شکل ‏4‑1 TFTPشکل ‏4‑1 TFTPبرای کپی فایل config سوئیچ مراحل زیر را انجام دهیدفعال کردن سرویس TFTP بر روی server شکل ‏4‑2 فعال کردن سرویس tftpشکل ‏4‑2 فعال کردن سرویس tftpبعد از ip دادن به sever از فرمان زیر در سوئیچ استفاده کنیدبرنامه ‏4‑1 copy conf fileenCopy run-configuration tftpXxx.xxx.xxx.xxxبرنامه ‏4‑1 copy conf fileشما به جای xxx.xxx.xxx.xxx. ipای که به server اختصاص داده‌اید را وارد کنید.شما می‌توانید برای کپی فایل flash و یا startup فرمان برنامه ‏4‑1 copy conf file را وارد کرده و به جای کلمه run-configuration از کلمات flash و یا startup استفاده کنید.5-1چگونگی Resort فایل از TFTP serverبرای برداشتن فایل از TFTP server مانند زیر عمل کنیدenCopy tftp run-configurationبرنامه ‏4‑2 resort fileکه برای resort فایل flash و startup کافی است یه جای run.. از کلمه flash و startup استفاده کنیم.6 باز گشت switch به حالت اولیهبرای این کار مطابق زیر عمل کنید برنامه ‏5‑1reset configuration برنامه ‏5‑2 reset switchenEraser startup-configReloadبرنامه ‏5‑1 reset configurationenWriting eraserReloadبرنامه ‏5‑2 reset switch7 مشکلات بوجود آمده در زمان راه اندازی سوئیچ‌هاکابلی که برای برقراری ارتباط بین دو سوئیچ استفاده می‌شود باید رنگ بندی خاصی را داشته باشدبرای درست کردن چنین کابلی باید مانند زیر عمل کنیمیک طرف کابل را به صورت عادی سوکت می‌زنیم شکل ‏6‑1رنگ بندی کابلسفید نارنجی , نارنجی ٬ سفید سبز ٬ آبی ٬ سفید آبی ٬ سبز ٬ سفید قهوه‌ای ٬ قهوه‌ایشکل ‏6‑1رنگ بندی کابلطرف دیگر را باید مانند رنگ بندی زیر سوکت بزنیدشکل ‏6‑2 رنگ بندی برای سوئیچسبز سفید ٬ سبز ٬ سفید نارنجی ٬ سفید قهوه‌ای ٬ قهوه‌ای ٬ نارنجی ٬ آبی ٬ آبی سفیدشکل ‏6‑2 رنگ بندی برای سوئیچhttps://teaching.iranmodares.com/teaching-index.php?metaword=%D9%85%D8%AD%D9%85%D8%AF+%D8%AD%D8%B3%DB%8C%D9%86+%D8%AC%D9%84%DB%8C%D9%84%DB%8C

توضیحات DDD, CQRS و Event Sourcing

محمد حسین جلیلی — Fri, 10 Dec 2021 16:59:52 +0330
1 توضیحات DDD, CQRS و Event Sourcingمیکروسرویس ها از حدود سال 2014 شروع به محبوب شدن کردند، اگرچه این اصطلاح چند سال قبل از آن ابداع شد. با گسترش علاقه، متأسفانه این اصطلاح مبهم شده است و امروزه میکروسرویس ها معمولاً فقط به عنوان یک معماری سیستم توزیع شده در نظر گرفته می شوند.در طول سال‌های اخیر، هم معماری رویداد محور (EDA) و هم event sourcing، تا حدی به دلیل علاقه به میکروسرویس‌ها که نیازمند راه‌های مؤثری برای برقراری ارتباط بین سرویس‌ها است، توجه فزاینده‌ای را به خود جلب کرده‌اند. این مفاهیم همچنین باعث ایجاد سردرگمی در مورد معنای واقعی آنها و نحوه تأثیر آنها بر معماری و طراحی برنامه ها شده است.در این نوشته، مفاهیم اساسی، سوء تفاهم‌های رایجی را که دیده‌ایم و اینکه چگونه پلتفرم Axon با ارائه پایه‌ای برای ساختن سیستم‌های پیام محور ناهمزمان بر اساس مفاهیم میکرو سرویس‌ها، معماری رویداد محور و event sourcing کمک می‌کند، توضیح می‌دهیم. اما با استفاده از همان مفاهیم و ایده‌های اولیه، آکسون همچنین از توسعه برنامه‌هایی پشتیبانی می‌کند که به صورت یکپارچه شروع می‌شوند و بعداً با تغییر نیازمندی‌های مجدد به میکرو سرویس‌های مبتنی بر رویداد تبدیل می‌شوند، بدون اینکه نیازهای مجدد و اساسی را تغییر دهند.1-1 طراحی دامنه محور (DDD)طراحی دامنه محور یا DDD یک رویکرد مهم در هنگام کار با دامنه های پیچیده و حتی در زمینه میکروسرویس ها مهمتر است. DDD بیش از 15 سال است که وجود داشته است، اما به دلیل میکرو سرویس ها، علاقه بیشتری به خود جلب کرده است. مفاهیمی مانند bounded context برای یافتن مرزهای بین ماژول ها یا services from a business perspective مهم هستند، چه در برنامه های کاربردی یکپارچه یا میکروسرویس ها. زبان فراگیر یکی دیگر از مفاهیم مهم است - زبان مشترکی که توسط توسعه دهندگان، افراد تجاری و سایر افراد درگیر در یک زمینه محدود خاص برای بهبود درک و به حداقل رساندن خطر سوء تفاهم استفاده می شود.اصطلاح Aggregates یک اصطلاح در سطح فنی تر است و مجموعه ای از موجودیت ها را توصیف می کند که با هم کار می کنند. یک Aggregates از یک یا چند موجودیت تشکیل شده است که همیشه باید سازگار باشند - Aggregates یک مرز ثبات تراکنش یا transactional consistency boundary است. پس از یک یا چند تغییر از موجودیت‌های موجود در یک Aggregates، باید همیشه زمانی که تراکنش انجام می‌شود، ثابت بماند. به خصوص در سیستم های توزیع شده و در نهایت سازگار، Aggregates یک مفهوم اساسی برای اطمینان از صحت در طولانی مدت است.1-2 معماری رویداد محوربا افزایش استفاده از میکروسرویس ها، تقاضا برای ارتباط بین تمام سرویس‌ها نیز وجود دارد. رویدادها یک راه عالی برای توزیع ناهمزمان اطلاعات در مورد چیزهایی است که در سطح کسب و کار در یک سرویس اتفاق می افتد. خدمات مشتری می تواند اطلاعاتی در مورد مشتریان جدید یا اینکه مشتری به آدرس جدیدی نقل مکان کرده است منتشر کند. اما وقایع کافی نیستند. دستورات و پرس و جوها دو نوع پیام هستند که برای دستیابی به یک برنامه کاربردی خوب طراحی شده بر اساس معماری «رویداد محور» نیز ضروری هستند، بنابراین این نوع معماری را باید معماری پیام محور نامید.بخش مهمی از انتشار رویدادها این است که ناشر اهمیتی نمی‌دهد که کسی گوش می‌دهد، اگر کسی به رویدادهای منتشر شده گوش نمی‌دهد، سرویس ناشر همچنان باید بتواند وظایف خود را انجام دهد.امروزه یک سوء تفاهم رایج وجود دارد که سرویسی که می خواهد کاری در سرویس دیگری انجام شود، رویدادی را منتشر می کند. این امر باعث ایجاد مسئولیتی می‌شود بر روی نتیجه وظایف کسب‌و‌کار و اغلب نیاز به نظارت دقیق بر همه رویدادهای مجزا را در تلاش برای یافتن مشکلات در جریان تجاری ایجاد می کند. این عدم قطعیت بسیار نزدیک به سبک pinball machine architecture است که گاهی اوقات در ارتباط با معماری بدون سرور ذکر می شود، جایی که درک اینکه داده ها کجا هستند و چه توابعی فراخوانی می شوند دشوار است.اگر ناشر انتظار دارد اتفاقی بیفتد، در عوض باید درخواستی را به صورت ناهمزمان به سرویس دیگری به عنوان یک فرمان ارسال کند و سپس به صورت ناهمزمان منتظر نتیجه باشد. این امر به وضوح نشان می دهد که سرویس ارسال کننده فرمان مسئول انجام وظیفه تجاری در دست است.یک مثال، خدمات انجام سفارش است که قبل از ادامه سفارش، نیاز به پرداخت برای سفارش دارد. این سرویس یک فرمان ناهمزمان را به یک سرویس پرداخت ارسال می کند. هنگامی که پرداخت تکمیل شد، سرویس پرداخت موفقیت آمیز یا شکست را در صورت عدم پرداخت برمی گرداند. پیام برگشت توسط سرویس انجام سفارش دریافت می شود که اکنون می تواند سفارش را ادامه دهد و در صورت موفقیت آمیز بودن پرداخت، درخواست ارسال کند. در این سناریو، سرویس انجام سفارش از یک سرویس پرداخت آگاه است، که درست است، اما سرویس پرداخت از این که پرداخت برای چه منظوری انجام می‌شود، آگاه نیست. اگر کسب‌وکار اکنون تصمیم بگیرد قبل از دریافت وجه به مشتری معتمد ارسال کند، این امر به راحتی در سرویس انجام سفارش بدون دست زدن به هیچ سرویس دیگری قابل رسیدگی است. در یک رویکرد صرفاً مبتنی بر رویداد، این تغییر مستلزم تغییراتی در حداقل چند سرویس و به طور بالقوه در بسیاری از خدمات است. در این سناریو، سرویس پرداخت مسئولیت کامل رسیدگی به پرداخت را دارد که ممکن است شامل درخواست از مشتری برای کارت اعتباری جدید یا سایر اطلاعات باشد تا بتواند پرداخت را تکمیل کند. این فرآیند ممکن است ساعت ها یا حتی روزها طول بکشد اگر مشتری هرگز به پرداخت ناموفق پاسخ ندهد، اما این مشکلی نیست. اگر پرداخت هرگز تکمیل نشود، در نهایت سرویس Paymentپرداخت را لغو می کند و نقصی را به سرویس درخواست کننده برمی گرداند. رویدادها باید بر رفتار تمرکز داشته باشند و با رویدادهای سطح تجاری مطابقت داشته باشند. یک سرویس نباید فقط رویدادهایی را منتشر کند که داده‌ها تغییر کرده‌اند، بلکه باید تغییراتی را توصیف کند که برای کسب‌وکار معنی دارند. به جای رویداد CustomerChanged که هنگام انتقال مشتری به آدرس جدید منتشر می شود، رویداد بهتر ممکن است CustomerMoved باشد. مدل‌سازی رویدادها به این روش به جای تمرکز بر ساختار، تمرکز رفتاری را مجبور می‌کند، که از منظر DDD سودمند است و درک آنچه یک برنامه کاربردی انجام می‌دهد را آسان‌تر می‌کند. رویدادهایی که از رویدادهای دنیای واقعی در دامنه تقلید می‌کنند، اغلب منجر به تغییرات کمتری نیز می‌شوند، زیرا دامنه‌ها اغلب تغییر نمی‌کنند.1-3 رویدادها و پیام هاهمانطور که قبلاً توضیح داده شد، سه نوع اصلی پیام در EDAوجود دارد:یک رویداد نشان دهنده چیزی است که اتفاق افتاده است. آنها یک واقعیت تغییر ناپذیر هستند و بنابراین نمی توان آنها را تغییر داد یا حذف کرد.یک فرمان عملی را نشان می دهد که فرستنده می خواهد گیرنده آن را انجام دهد. سپس نتیجه اجرا به فرستنده بازگردانده می شود. دستورات همیشه دقیقاً یک مقصد دارند.پرس و جو بیانگر درخواست اطلاعاتی است که فرستنده از یک یا چند گیرنده می خواهد. سپس داده های درخواستی واکشی شده و به فرستنده بازگردانده می شود.یکی از جنبه های مهم رویدادها این است که آنها تغییر ناپذیر هستند، آنها نشان دهنده واقعیت چیزی هستند که اتفاق افتاده است و هرگز نباید به روز یا حذف شوند. یکی از گزینه‌های زمانی که نیاز به تغییر یا حذف رویدادها ایجاد می‌شود، می‌توان یک جریان رویداد خروجی جدید ایجاد کرد و برای ایجاد رویدادهای جدید از جریان غیرقابل تغییر اصلی رویدادها استفاده کرد.1-4 سازگاری نهاییجهان در نهایت سازگار است. انتقال پول بین دو حساب در بانک های مختلف زنجیره ای از نقل و انتقالات است که در نهایت به درستی در هر دو حساب منعکس خواهد شد. متأسفانه، سازگاری قوی برای مدت طولانی در جامعه نرم افزاری معمول بوده است. همه چیز باید هماهنگ باشد، حتی گاهی اوقات بین سرویس ها، که به معنای استفاده از انواع مختلف پروتکل های تراکنش پیچیده است که پیچیدگی های غیر ضروری زیادی را به سیستم ها اضافه کرده است. با میکروسرویس‌ها، جامعه نرم‌افزاری سازگاری نهایی را اتخاذ می‌کنند. تغییرات در یک سرویس با استفاده از رویدادها، پیام ها یا اشکال دیگر حمل و نقل به سرویس های دیگر منتقل می شود که در نهایت با سرویس ارسال کننده سازگار خواهد بود. اما درک این نکته نیز حائز اهمیت است که هر مجموع فردی که در آن تصمیم‌گیری می‌شود، باید همیشه سازگار باشد. این نتیجه این تصمیمات است که در نهایت برای سایر مؤلفه ها "مشاهده" می شود. در حالی که سازگاری نهایی یک مفهوم اجتناب ناپذیر در سیستم های توزیع شده در مقیاس بزرگ است، همه چیز در چنین سیستمی در نهایت سازگار نیست. تصمیمات خاصی در حوزه کسب و کار هرگز نباید بر اساس داده های متناقض اتخاذ شوند. در یک سیستم در نهایت سازگار، چندین مؤلفه جداگانه وجود دارد که از نظر داخلی کاملاً سازگار هستند. مجموعه ای که قبلا توضیح داده شد، چنین جزء است. این مؤلفه‌های کاملاً سازگار اجازه می‌دهند تا تصمیم‌گیری‌ها بر اساس یک منبع اطلاعاتی قابل اعتماد و ثابت گرفته شود، در حالی که نتایج آن تصمیم‌ها در نهایت در سایر مؤلفه‌ها به‌روزرسانی می‌شوند.1-5الگوی CQRSالگوی Command Query Responsibility Segregation (CQRS) یک مفهوم کاملا ساده است. بیان می کند که اجرای یک دستور باید از حالت بازگشتی کوئری ها جدا شود. برای یک سیستم نرم افزاری این بدان معنی است که بخشی که وضعیت را تغییر می دهد از بخشی که وضعیت را درخواست می کند جدا می شود.این چندین مزیت دارد. یک دستور باید تنها بر یک مجموعه تأثیر بگذارد، در حالی که یک پرس و جو اغلب مقدار بیشتری از داده ها یا لیستی از داده ها را بازیابی می کند، به این معنی که می توانیم تأثیر نوشتن را به حداقل برسانیم و مقدار داده های بازیابی شده را بهینه کنیم. همچنین می توان از انواع جداگانه ذخیره سازی برای نوشتن و خواندن استفاده کرد که استفاده از منبع رویداد را امکان پذیر می کند. اغلب خواندن باید عملکرد بیشتری نسبت به نوشتن داشته باشد و با یک مدل خواندن جداگانه می توان این مدل را برای خواندن بهینه کرد.اما این جداسازی همچنین به این معنی است که مدل خوانده شده با اتفاقاتی که در سمت نوشتن اتفاق می افتد به روز می شود. انجام این کار به صورت ناهمزمان به این معنی است که ممکن است یک فرمان در خواندن بلافاصله پس از آن منعکس نشود، خود برنامه اکنون در نهایت سازگار است که ممکن است به عنوان مثال یک رابط کاربری گرافیکی در نظر گرفته شود.1-6 منبع یابی رویدادایده‌های منبع‌یابی رویداد جدید نیستند، سیستم‌ها گاهی اوقات از مدت‌ها پیش به این روش در مین‌فریم‌ها ساخته می‌شدند، و پایگاه‌های داده اغلب با منبع‌یابی رویداد به صورت داخلی کار می‌کنند.در منبع‌یابی رویداد، وضعیت یک واحد تجاری به‌عنوان یک توالی ترتیب‌بندی شده از رویدادها باقی می‌ماند.هنگامی که وضعیت موجودیت تغییر می کند، یک رویداد جدید به لیست رویدادها اضافه می شود. وضعیت فعلی موجودیت با پخش مجدد همه رویدادها ایجاد می شود. ذخیره دوره ای یک عکس فوری از وضعیت فعلی راهی برای بهینه سازی بارگذاری زمانی است که یک موجودیت دارای تعداد زیادی رویداد است.هنگام استفاده از منبع رویداد در یک جزء یا یک سرویس، یک مسیر حسابرسی کامل و قابل اعتماد از آن سرویس دریافت می کنید. وضعیت گذشته همچنین می تواند با پخش مجدد همه رویدادها تا یک نقطه زمانی خاص بازسازی شود که می تواند هنگام ارزیابی نتیجه اشکالات در یک سیستم مفید باشد. همچنین انتقال از منبع رویداد به حالت ذخیره‌سازی با رویدادها به‌عنوان اثر جانبی آسان است، اما برعکس نه.معمولاً کل سیستم نباید منبع رویداد باشد. در عوض، استفاده از منبع رویداد باید تصمیمی باشد که در هر زمینه محدود یا احتمالاً در مجموع اتخاذ می شود. یک استدلال مهم برای زمان استفاده از منبع رویداد این است که آیا انتقال حالت بخش مهمی از فضای مشکل است و باید در دامنه مدل شود.همانطور که قبلا ذکر شد، مدل سازی با استفاده از رویدادها، بسیاری از مشکلات در یک دامنه برطرف می شود. در صنایعی مانند مالی، بانکداری یا بیمه، مفهوم منبع رویداد اغلب استفاده می شود. یکی از دلایل نیاز به نگه داشتن هر چیزی است که اتفاق می افتد.رویدادهای منبع رویداد نباید خارج از زمینه محدود منتشر شوند. در یک زمینه، همه سرویس‌ها به یک زبان صحبت می‌کنند و می‌توانند همه رویدادها را بفهمند و ممکن است به اشتراک بگذارند، انتشار به بیرون وابستگی‌های غیرضروری ایجاد می‌کند. در عوض، رویدادهای دامنه را برای رابط منتشر شده یک زمینه ایجاد کنید. یک استثنا در این مورد خدماتی است که برای تجزیه و تحلیل یا گزارش استفاده می شود.یکی از آرگومان‌هایی که اغلب برای منبع‌یابی رویداد استفاده می‌شود، امکان پخش مجدد رویدادها در صورت تشخیص خطا است. این می تواند برای سرویسی که پخش مجدد را انجام می دهد بی ضرر به نظر برسد - فقط تمام یا بخشی از یک جریان رویداد را از سرویس دیگری پخش می کند و حالت آن را بازسازی می کند. اما اگر این سرویس رویدادها را نیز منتشر کند، پخش مجدد احتمالاً روی این رویدادهای قبلاً منتشر شده که قبلاً توسط سرویس‌های پایین‌تر زنجیره مصرف شده‌اند تأثیر خواهد داشت. این باعث ایجاد یک اثر موج دار با تأثیر غیرقابل پیش بینی بر کل سیستم می شود. اگر یک رویداد در عمل به‌عنوان یک فرمان مدیریت شود - یک سفارش داده شده است - ممکن است منجر به دو بار انجام سفارش شود. بنابراین، پخش مجدد باید با دقت انجام شود و تصمیم بگیرد که آیا نتیجه یک رویداد خوانده شده باید انجام شود یا خیر.1-7 شفافیت مکانیکی از مفاهیم مهم برای فعال کردن حرکت از یکپارچه به میکروسرویس ها شفافیت مکان است - یک جزء نباید از مکان آن آگاه باشد و یا هیچ فرضی در مورد مکان یک جزء که با آن تعامل دارد نداشته باشد. این اجازه می دهد تا یک سیستم از یک یکپارچه ساختاریافته، که در آن همه اجزا به عنوان بخشی از یک واحد مستقر می شوند، به یک سیستم میکروسرویس، با هر جزء به صورت جداگانه، مهاجرت کند. همه چیز بدون هیچ تغییری در کد انجام شد. معمولاً شفافیت مکان با استفاده از پیام رسانی به شکلی انجام می شود.1-8 رویدادها و پیام هامعماری یک برنامه یا سیستم جدید باید تا حد امکان ساده باشد اما همچنان در صورت نیاز امکان رشد را فراهم کند. یک شروع عالی برای بسیاری از سیستم‌ها، پیام‌محور ماژولار و یکپارچه مبتنی بر مولفه است، رویدادی که در قسمت‌هایی که نیاز است منبع داده می‌شود. احتمالاً از سبک معماری شش ضلعی در داخل استفاده می کند و به پلتفرم Axon تکیه می کند تا بیشتر زیرساخت ها را فراهم کند و در صورت موفقیت آمیز بودن استفاده از برنامه، امکان مهاجرت به میکروسرویس ها را فراهم کند. این سبک ساختن یکپارچه حتی اگر هرگز در میکروسرویس ها تقسیم نشود، سودمند است. تعمیر و نگهداری، به روز رسانی منطق تجاری و غیره را ساده می کند.1-9 تقسیم معماریاگر مونولیت از همان ابتدا برای این کار ساخته شده باشد و از Axonاستفاده کند، به تدریج از یک مونولیت مدولار به میکروسرویس تبدیل می شود. هر میکروسرویس به‌طور مستقل مقیاس‌پذیر می‌شود و به آن اجازه می‌دهد تا جنبه‌های غیرعملکردی خاص هر نمونه میکروسرویس را بررسی کند.2 چارچوب Axonاکسون یا Axon یک چارچوب و یک سرور، هر دو منبع باز است که با هم یک پلتفرم برای سیستم‌های مبتنی بر میکروسرویس‌های رویداد محور ایجاد می‌کند که پایه و زیرساخت مورد نیاز برای طراحی و پیاده‌سازی موفق سیستم‌هایی را فراهم می‌کند که بر چالش‌های توصیف‌شده غلبه کنند. در Axon تمام ارتباطات بین اجزا با استفاده از اشیاء پیام انجام می شود. این به این مؤلفه‌ها شفافیت مکان مورد نیاز را می‌دهد تا بتوان در صورت لزوم، بدون هیچ تغییری در منطق تجاری، این مؤلفه‌ها را مقیاس و توزیع کرد. همچنین به این معنی است که یک برنامه تنها در صورتی باید در واحدهای قابل استقرار تقسیم شود که الزامات غیر کاربردی مانند اندازه تیم، چرخه انتشار، الزامات در دسترس بودن، عملکرد و غیره به آن نیاز داشته باشند.2-1 چارچوب آکسونچارچوب Axon بلوک های سازنده برنامه های کاربردی را بر اساس اصولی مانند DDD، CQRS و منبع یابی رویداد فراهم می کند. Axon Frameworkبرای جدا کردن منطق تجاری از نگرانی‌های زیرساختی طراحی شده است و از یک رویکرد تکاملی با پشتیبانی یکپارچه برای تبدیل به میکرویسرویس‌ها پشتیبانی می‌کند.آکسون به شدت جداسازی منطق را به اجزای کوچکتر تحریک می کند که از طریق پیام ها با یکدیگر ارتباط برقرار می کنند. این به طور قابل توجهی بار ذهنی را بر روی توسعه دهندگانی که با مؤلفه های خاص کار می کنند کاهش می دهد و به آنها اجازه می دهد به جای تمام زیرساخت های مورد نیاز برای مدیریت پیام ها، روی منطق مرتبط با یک پیام خاص تمرکز کنند. شفافیت مکان یک عنصر کلیدی در چارچوب است که تضمین می‌کند که یک مؤلفه در ارتباط با مؤلفه دیگر نیازی به دانستن مکان آن مؤلفه دیگر ندارد.همانطور که قبلا ذکر شد، پخش مجدد رویدادها می تواند بسیار پیچیده باشد. Axon Framework کنترل گرانول را برای کنترل کننده رویدادها از این نظر که رویدادها دوباره پخش می شوند و کدام نه، فراهم می کند. همچنین، امکان نظارت بر روند پخش مجدد وجود دارد.2-2 سرور AxonسرورAxon یک مسیریاب پیام و یک فروشگاه رویداد است که در یک محیط توزیع شده استفاده می شود.سرور Axon مسئول مسیریابی پیام ها بین تمام سرویس ها است. در مورد انواع مختلف پیام هایی که استفاده می شود اطلاعات دارد و می داند که چگونه با هر نوع برخورد کند. رویدادها از یک سرویس به یک یا چند سرویس دیگر ارسال می‌شوند، فرمان‌ها برای انجام کاری به یک سرویس ارسال می‌شوند، به طور بالقوه منتظر هستند و نتیجه را برمی‌گردانند، و درخواست‌ها برای بازیابی اطلاعات به یک یا چند سرویس ارسال می‌شوند و همیشه یک نتیجه را برمی‌گردانند.سرور Axon همچنین شامل یک فروشگاه رویداد هدفمند است که برای ذخیره رویدادهای ایجاد شده توسط مجموعه های منبع رویداد استفاده می شود. هنگام ذخیره رویدادها، رویداد را به شنوندگان و پردازشگرهای رویدادی که در حال اجرا هستند نیز هدایت می کند، بنابراین نیاز به نظرسنجی منظم و تأخیر ناشی از آن را از بین می برد. یکی از ویژگی های مهم عملکرد ثابت صرف نظر از اندازه ذخیره سازی است. تعداد رویدادها در یک سیستم منبع رویداد می تواند بسیار زیاد باشد و حافظه ای که با پر شدن کندتر می شود منجر به کاهش عملکرد قابل توجه برای کل سیستم سایر ویژگی های مهم عبارتند از امکان اضافه کردن چندین رویداد در یک تراکنش، snapshot برای ذخیره وضعیت فعلی یک مجموع، بنابراین از نیاز به خواندن تعداد زیادی رویداد برای ایجاد حالت اجتناب می شود. همچنین برای رویدادهای اخیر بهینه شده است. به خصوص هنگام استفاده از snapshot، فقط آخرین رویدادها از فروشگاه خوانده می شود.همانطور که قبلاً توضیح داده شد، پخش مجدد رویدادها باید با دقت انجام شود. رویدادهایی که به صورت عمومی منتشر می شوند یا کنترل کننده رویداد با برخی از سیستم های خارجی تماس می گیرند، می توانند مشکلات بزرگ و غیرقابل جبرانی ایجاد کنند. در Axon، هنگام پخش مجدد رویدادها، دروازه های سیستم های دیگر را می توان غیرفعال کرد. Axonهمچنین کنترل گرانول را بر روی گردانندگان رویداد فراهم می کند تا تصمیم بگیرند کدام مؤلفه ها برای پخش مجدد رویدادهای خود نیاز دارند.نسخه‌ی Axon Server Enterprises دارای قابلیت اجرا در یک محیط خوشه ای است. این کمک می کند تا اطمینان حاصل شود که هر گونه شکست یک گره منفرد بر در دسترس بودن خوشه به عنوان یک کل تأثیر نمی گذارد، و به آن تضمین های در دسترس بودن می دهد که ممکن است از هر سیستم درجه تولید انتظار داشته باشید. پشتیبانی چند متنی Axon Serverبه تیم‌ها یا بخش‌های جداگانه اجازه می‌دهد تا محیط مجازی خود را بر روی یک کلاستر مستقر در مرکز مدیریت کنند و عملیات در محیط‌های سازمانی را ساده‌تر کند.«این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است»

شروعی برای یادگیری طراحی با محوریت دامنه

محمد حسین جلیلی — Fri, 10 Dec 2021 14:26:29 +0330
1 پیشگفتاری از Abel Avramاز DDDاولین بار در مورد طراحی Domain Driven شنیدم و اریک ایوانز را در یک گردهمایی کوچک از معماران در یک اجلاس کوهستانی که توسط بروس ایکل در تابستان 2005 سازماندهی شده بود ملاقات کردم. در این اجلاس تعدادی از افراد مورد احترام من شرکت کردند، از جمله مارتین فاولر، راد جانسون، کامرون. پردی، رندی استافورد و گرگور هوپ.به نظر می رسید این گروه کاملاً تحت تأثیر دیدگاه طراحی Domain Drivenقرار گرفته است و مشتاق کسب اطلاعات بیشتر در مورد آن بودند. همچنین این احساس را داشتم که همه آرزو می‌کردند که این مفاهیم بیشتر در جریان اصلی قرار بگیرند. وقتی متوجه شدم که اریک چگونه از مدل دامنه برای بحث در مورد راه‌حل‌هایی برای چالش‌های فنی مختلف مورد بحث گروه استفاده می‌کند، و چقدر بر حوزه کسب‌وکار به‌جای تبلیغات ویژه فناوری تأکید می‌کند، بلافاصله فهمیدم که این دیدگاهی است که جامعه به شدت نیاز دارد.ما، در جامعه توسعه سازمانی، به‌ویژه جامعه توسعه وب، سال‌ها با هیاهویی که ما را از توسعه نرم‌افزار شی گرا مناسب دور کرد، آلوده شده‌ایم. در جامعه جاوا، مدل‌سازی دامنه خوب در هیاهوی EJB و مدل‌های کانتینر/کامپوننت سال‌های 1999-2004 از بین رفت. خوشبختانه، تغییرات در فناوری و تجربیات جمعی جامعه توسعه نرم افزار ما را به سمت پارادایم های شی گرا سنتی سوق می دهد. با این حال، جامعه فاقد دیدگاه روشنی برای نحوه اعمال شی گرایی در مقیاس سازمانی است، به همین دلیل است که فکر می کنم DDDمهم است.2 معرفینرم افزار ابزاری است که به ما کمک می کند تا با پیچیدگی های زندگی مدرن خود مقابله کنیم. نرم افزار فقط وسیله ای برای رسیدن به هدف است و معمولاً این هدف چیزی بسیار عملی و واقعی است. به عنوان مثال، ما از نرم افزاری برای کنترل ترافیک هوایی استفاده می کنیم و این ارتباط مستقیمی با دنیای اطراف ما دارد. ما می‌خواهیم از مکانی به مکان دیگر پرواز کنیم، و این کار را با استفاده از ماشین‌آلات پیشرفته انجام می‌دهیم، بنابراین نرم‌افزاری را برای هماهنگ کردن پرواز هزاران هواپیما که در هر زمان در هوا هستند ایجاد می‌کنیم.نرم افزار باید کاربردی و مفید باشد. در غیر این صورت ما زمان و منابع زیادی را برای ایجاد آن سرمایه گذاری نمی کنیم. این باعث می شود که آن را به جنبه خاصی از زندگی ما بسیار مرتبط کند. یک بسته نرم افزار مفید را نمی توان از آن حوزه واقعیت جدا کرد، دامنه ای که قرار است به ما در مدیریت آن کمک کند. برعکس، نرم افزار عمیقاً با آن درگیر شده است.طراحی نرم افزار یک هنر است و مانند هر هنری نمی توان آن را به عنوان یک علم دقیق و با قضایا و فرمول ها آموخت و آموخت. ما می‌توانیم اصول و تکنیک‌هایی را کشف کنیم که برای استفاده در طول فرآیند ایجاد نرم‌افزار مفید هستند، اما احتمالاً هرگز نخواهیم توانست مسیر دقیقی را برای دنبال کردن از نیاز دنیای واقعی به ماژول کدی که برای پاسخگویی به آن نیاز است، ارائه دهیم. مانند یک تصویر یا یک ساختمان، یک محصول نرم افزاری شامل لمس شخصی کسانی است که آن را طراحی و توسعه داده اند، چیزی از جذابیت و استعداد (یا فقدان آن) کسانی که در پیدایش و رشد آن سهیم بوده اند.روش های مختلفی برای رویکرد طراحی نرم افزار وجود دارد. در 20 سال گذشته، صنعت نرم افزار روش های مختلفی را برای ایجاد محصولات خود می شناسد و از آنها استفاده می کند که هر کدام مزایا و معایب خود را دارند. هدف این نوشته تمرکز بر روش طراحی است که در دو دهه اخیر ظهور و تکامل یافته است، اما در چند سال اخیر به وضوح تبلور یافته است: طراحی دامنه محور. اریک ایوانز با نوشتن در یک کتاب بسیاری از دانش انباشته شده در مورد طراحی دامنه محور کمک زیادی به این موضوع کرده است. برای ارائه دقیق‌تر این موضوع، توصیه می‌کنیم کتاب «طراحی دامنه محور: مقابله با پیچیدگی در قلب نرم‌افزار»، منتشر شده توسط Addison-Wesley، ISBN: 0-321-12521-5 را مطالعه کنید.بسیاری از بینش‌های ارزشمند را نیز می‌توان با دنبال کردن گروه بحث طراحی Domain Driven در:http://groups.yahoo.com/group/domaindrivendesignاین نوشته تنها مقدمه‌ای برای موضوع است و قصد دارد به سرعت درک اساسی، اما نه جزئی از طراحی دامنه را به شما بدهد. من فقط می خواهم اشتیاق شما را برای طراحی نرم افزار خوب با اصول و دستورالعمل های مورد استفاده در دنیای طراحی دامنه محور باز کنم.3 طراحی بر مبنای دامنه یا طراحی دامنه محور چیست؟توسعه نرم افزاری اغلب برای خودکارسازی فرآیندهایی که در دنیای واقعی وجود دارند، یا ارائه راه حل هایی برای مشکلات کسب و کار استفاده می شود. فرآیندهای کسب و کار خودکار شده‌اند یا مشکلات جهان واقعی که نرم افزار راه حلی برای دامنه‌ای از مشکلات است. ما باید از ابتدا درک کنیم که نرم افزار از این حوزه نشات گرفته و عمیقاً با آن مرتبط است.نرم افزار از کد تشکیل شده است. ممکن است وسوسه شویم که زمان زیادی را با کد صرف کنیم و نرم افزار را صرفاً به عنوان اشیا و روش ببینیم.خودروسازی را به عنوان یک استعاره در نظر بگیرید. کارگرانی که در ساخت خودرو فعالیت می کنند ممکن است در تولید قطعات خودرو تخصص داشته باشند، اما در انجام این کار اغلب دید محدودی از کل فرآیند تولید خودرو دارند. آنها شروع به نگاه کردن به ماشین به عنوان مجموعه عظیمی از قطعات می کنند که باید در کنار هم قرار گیرند، اما یک ماشین بسیار بیشتر از این است. یک ماشین خوب با یک دید شروع می شود. با مشخصات دقیق نوشته شده شروع می شود. و با طراحی ادامه می یابد. طراحی زیاد و زیاد. ماه ها، شاید سال ها زمان صرف طراحی، تغییر و اصلاح آن تا زمانی که به کمال برسد، تا زمانی که چشم انداز اصلی را منعکس کند. طراحی، پردازش همه‌ی اجزا بر روی کاغذ نیست. بخش اعظمی از آن شامل انجام مدل‌های خودرو و آزمایش آن‌ها در شرایط خاص است تا ببینیم آیا کار می‌کنند یا خیر. طراحی بر اساس نتایج آزمایش اصلاح شده است. خودرو در نهایت به تولید ارسال می شود و قطعات با هم ساخته و مونتاژ می شوند.توسعه نرم افزار نیز مشابه است. ما نمی توانیم فقط بنشینیم و کد را تایپ کنیم. ما می‌توانیم این کار را انجام دهیم، و برای موارد بی‌اهمیت به خوبی کار می‌کند. اما ما نمی توانیم نرم افزار پیچیده ای مانند آن ایجاد کنیم.برای ایجاد نرم افزار خوب، باید بدانید که آن نرم افزار چیست. شما نمی توانید یک سیستم نرم افزاری بانکی ایجاد کنید مگر اینکه درک خوبی از چیستی بانکداری داشته باشید، باید حوزه بانکداری را درک کنید.آیا می توان نرم افزار پیچیده بانکی را بدون دانش خوب حوزه ایجاد کرد؟ به هیچ وجه. هرگز.چه کسی بانکداری می داند؟ معمار نرم افزار؟ نه. او فقط از بانک استفاده می‌کند تا پول‌هایش را ایمن نگه دارد و در صورت نیاز در دسترس باشد.تحلیلگر نرم افزار؟ نه واقعا. او می داند که یک موضوع مشخص را تجزیه و تحلیل کند، زمانی که همه مواد لازم به او داده می شود.توسعه دهنده؟ فراموشش کن. پس کی؟ البته بانکداران سیستم بانکی را کارکنان داخل و متخصصان آنها به خوبی درک می کنند. آنها همه جزئیات، همه چیزها، همه مسائل احتمالی، همه قوانین را می دانند. این جایی است که ما همیشه باید شروع کنیم: دامنه.هنگامی که یک پروژه نرم افزاری را شروع می کنیم، باید روی دامنه ای که در آن فعالیت می کند تمرکز کنیم. تمام هدف نرم افزار ارتقاء یک دامنه خاص است. برای انجام این کار، نرم افزار باید با دامنه ای که برای آن ایجاد شده است هماهنگ باشد. در غیر این صورت فشار وارد دامنه خواهد شد و باعث اختلال در عملکرد، آسیب و حتی ایجاد هرج و مرج می شود.چگونه می توانیم نرم افزار را با دامنه هماهنگ کنیم؟ بهترین راه برای انجام این کار این است که نرم افزار را بازتابی از دامنه کنید. نرم افزار باید مفاهیم و عناصر اصلی دامنه را در خود بگنجاند و روابط بین آنها را دقیقاً درک کند. نرم افزار باید دامنه را مدل کند.کسی که دانش بانکی ندارد باید بتواند فقط با خواندن کد در یک مدل دامنه، چیزهای زیادی یاد بگیرد. این ضروری است. نرم‌افزارهایی که ریشه‌های عمیقی در دامنه ندارند، در طول زمان به تغییرات واکنش خوبی نشان نمی‌دهند.بنابراین ما با دامنه شروع می کنیم. بعد چی؟ دامنه چیزی از این دنیاست. فقط نمی توان آن را گرفت و روی صفحه کلید داخل رایانه ریخت تا به کد تبدیل شود. ما باید یک انتزاع از دامنه ایجاد کنیم. هنگام صحبت با کارشناسان دامنه، چیزهای زیادی در مورد یک دامنه می آموزیم. اما این دانش خام به راحتی به ساختارهای نرم افزاری تبدیل نمی شود، مگر اینکه انتزاعی از آن، طرحی در ذهن خود بسازیم.در ابتدا، طرح اولیه همیشه ناقص است. اما به مرور زمان در حین کار آن را بهتر می کنیم و برایمان بیشتر و بیشتر روشن می شود. این انتزاع چیست؟ این یک مدل است، یک مدل از دامنه.به گفته اریک ایوانز، مدل دامنه یک نمودار خاص نیست. این ایده ای است که نمودار قصد دارد آن را منتقل کند. این فقط دانش در سر یک متخصص حوزه نیست. این یک انتزاع دقیق و منتخب از آن دانش است. یک نمودار می تواند یک مدل را نشان دهد و ارتباط برقرار کند، همانطور که می تواند کدهایی را که با دقت نوشته شده است، و همچنین یک جمله انگلیسی.مدل، نمایش داخلی ما از دامنه هدف است و در طول طراحی و فرآیند توسعه بسیار ضروری است. در طول فرآیند طراحی، مدل را به خاطر می آوریم و ارجاعات زیادی به آن می کنیم. دنیای اطراف ما بیش از آن است که مغز ما بتواند آن را کنترل کند. حتی یک حوزه خاص می تواند بیش از آن باشد که یک ذهن انسان در یک زمان آن را مدیریت کند. ما باید اطلاعات را سازماندهی کنیم، آنها را نظام‌مند کنیم، آن‌ها را به قطعات کوچک‌تر تقسیم کنیم، آن‌ها را در ماژول‌های منطقی گروه‌بندی کنیم، و هر بار یکی یکی بگیریم و به آن بپردازیم. حتی باید برخی از قسمت های دامنه را کنار بگذاریم. یک دامنه حاوی اطلاعات بسیار زیادی است که همه آن را در مدل گنجانده است. و بسیاری از آن حتی لازم نیست در نظر گرفته شود. این خود یک چالش است. چه چیزی را باید نگه داشت و چه چیزی را دور انداخت؟ این بخشی از طراحی، فرآیند ایجاد نرم افزار است. نرم افزار بانکی مطمئناً آدرس مشتری را پیگیری می کند، اما نباید به رنگ چشم مشتری اهمیت دهد. این یک مورد واضح است، اما نمونه های دیگر ممکن است چندان واضح نباشند.یک مدل جزء ضروری طراحی نرم افزار است. ما به آن نیاز داریم تا بتوانیم با پیچیدگی مقابله کنیم. تمام فرآیند تفکر ما در مورد دامنه در این مدل ترکیب شده است. این خوب است، اما باید از ذهن ما خارج شود.اگر در آنجا بماند زیاد مفید نیست، درست است؟ما باید با این مدل با کارشناسان دامنه، با طراحان همکار و با توسعه دهندگان ارتباط برقرار کنیم. مدل ماهیت نرم افزار است، اما ما باید راه هایی برای بیان آن ایجاد کنیم تا با دیگران ارتباط برقرار کنیم. ما در این فرآیند تنها نیستیم، بنابراین باید دانش و اطلاعات را به اشتراک بگذاریم و باید آن را به خوبی، دقیق، کامل و بدون ابهام انجام دهیم. راه های مختلفی برای انجام آن وجود دارد. یکی گرافیکی است: نمودارها، موارد استفاده، نقاشی ها، تصاویر و غیره. دیگری نوشتن است. ما دیدگاه خود را در مورد دامنه یادداشت می کنیم. دیگری زبان است. ما می‌توانیم و باید زبانی برای برقراری ارتباط مسائل خاص در مورد دامنه ایجاد کنیم. همه اینها را بعداً شرح خواهیم داد، اما نکته اصلی این است که ما باید مدل را با هم ارتباط دهیم.وقتی یک مدل بیان شده داریم، می توانیم طراحی کد را شروع کنیم. این با طراحی نرم افزار متفاوت است. طراحی نرم افزار مانند ایجاد معماری یک خانه است، در مورد تصویر بزرگ است. از سوی دیگر، طراحی کد روی جزئیات کار می کند، مانند مکان یک نقاشی روی یک دیوار خاص. طراحی کد نیز بسیار مهم است، اما نه به اندازه طراحی نرم افزار. اشتباه طراحی کد معمولاً راحت تر اصلاح می شود، در حالی که تعمیر خطاهای طراحی نرم افزار بسیار هزینه بر است. این یک چیز است که یک نقاشی را بیشتر به سمت چپ منتقل کنید، و یک چیز کاملاً متفاوت است که یک طرف خانه را خراب کنید تا آن را متفاوت انجام دهید. با این حال محصول نهایی بدون طراحی کد خوب خوب نخواهد بود. در اینجا الگوهای طراحی کد مفید هستند و در صورت لزوم باید از آنها استفاده شود. تکنیک های کدنویسی خوب به ایجاد کد تمیز و قابل نگهداری کمک می کند.روش های مختلفی برای طراحی نرم افزار وجود دارد. یکی روش طراحی آبشار است. این روش شامل چند مرحله است. کارشناسان کسب و کار مجموعه ای از الزامات را ارائه می کنند که به تحلیلگران کسب و کار ابلاغ می شود. تحلیلگران بر اساس آن الزامات، مدلی ایجاد می‌کنند و نتایج را به توسعه‌دهندگان می‌فرستند تا براساس آنچه دریافت کرده‌اند، کدنویسی را آغاز کنند. این یک جریان یک طرفه دانش است. در حالی که این یک رویکرد سنتی در طراحی نرم‌افزار بوده و در طول سال‌ها با موفقیت خاصی مورد استفاده قرار گرفته است، معایب و محدودیت‌های خود را دارد. مشکل اصلی این است که هیچ بازخوردی از سوی تحلیلگران به کارشناسان کسب و کار یا توسعه دهندگان به تحلیلگران وجود ندارد.روش دیگر روش های چابک است، مانند برنامه نویسی شدید (XP). این روش‌شناسی حرکتی جمعی علیه رویکرد آبشار است که ناشی از دشواری‌های تلاش برای ارائه همه الزامات از قبل، به ویژه در پرتو تغییر الزامات است. ایجاد یک مدل کامل که تمام جنبه های یک دامنه را از قبل پوشش دهد، واقعاً سخت است. این نیاز به تفکر زیادی دارد و اغلب شما نمی توانید از همان ابتدا همه مسائل مربوط به آن را ببینید و همچنین نمی توانید برخی از عوارض جانبی منفی یا اشتباهات طراحی خود را پیش بینی کنید. مشکل دیگری که Agileبرای حل آن تلاش می کند، به اصطلاح «فلج تحلیلی» است که اعضای تیم آنقدر از تصمیم گیری در مورد طراحی می ترسند که اصلاً پیشرفتی نمی کنند. در حالی که طرفداران Agile اهمیت تصمیم گیری در طراحی را تشخیص می دهند، در مقابل طراحی اولیه مقاومت می کنند. در عوض آن‌ها از انعطاف‌پذیری زیادی در پیاده‌سازی استفاده می‌کنند، و از طریق توسعه مکرر با مشارکت مستمر ذینفعان کسب‌وکار و بازآفرینی‌های زیاد، تیم توسعه اطلاعات بیشتری در مورد دامنه مشتری کسب می‌کند و بهتر می‌تواند نرم‌افزاری تولید کند که نیازهای مشتریان را برآورده کند.روش های چابک مشکلات و محدودیت های خاص خود را دارند. آنها طرفدار سادگی هستند، اما هر کسی دیدگاه خود را نسبت به معنای آن دارد. همچنین، بازسازی مداوم توسط توسعه دهندگان بدون اصول طراحی جامد، کدی را تولید می کند که درک یا تغییر آن سخت است. و در حالی که رویکرد آبشار ممکن است منجر به مهندسی بیش از حد شود، ترس از مهندسی بیش از حد ممکن است به ترس دیگری منجر شود: ترس از انجام یک طراحی عمیق و کاملاً فکر شده.این نوشته اصول طراحی مبتنی بر دامنه را ارائه می‌کند، که در صورت اعمال می‌تواند توانایی هر فرآیند توسعه را برای مدل‌سازی و پیاده‌سازی مشکلات پیچیده در دامنه به روشی قابل نگهداری تا حد زیادی افزایش دهد. Domain Driven Designطراحی و توسعه را با هم ترکیب می کند و نشان می دهد که چگونه طراحی و توسعه می توانند برای ایجاد راه حل بهتر با یکدیگر همکاری کنند. طراحی خوب توسعه را تسریع می کند، در حالی که بازخوردهای حاصل از فرآیند توسعه طراحی را بهبود می بخشد.4 ساخت دانش دامنهبیایید مثالی از پروژه سیستم کنترل پرواز هواپیما و نحوه ایجاد دانش دامنه را در نظر بگیریم.هزاران هواپیما در یک لحظه معین در سراسر کره زمین در هوا هستند. آنها مسیرهای خود را به سمت مقصد خود طی می کنند و بسیار مهم است که از برخورد آنها در هوا اطمینان حاصل شود. ما سعی نمی کنیم در مورد کل سیستم کنترل ترافیک توضیح دهیم، بلکه در مورد یک زیر مجموعه کوچکتر که یک سیستم نظارت بر پرواز است، توضیح خواهیم داد. پروژه پیشنهادی یک سیستم نظارتی است که هر پرواز را در یک منطقه خاص ردیابی می کند، تعیین می کند که آیا پرواز مسیر فرضی خود را دنبال می کند یا خیر، و آیا احتمال برخورد وجود دارد یا خیر.از دیدگاه توسعه نرم افزار از کجا شروع کنیم؟ در قسمت قبل گفتیم که باید با درک حوزه شروع کنیم که در این مورد نظارت بر ترافیک هوایی است. کنترلرهای ترافیک هوایی متخصصین این حوزه هستند. اما کنترل کننده ها طراح سیستم یا متخصص نرم افزار نیستند. شما نمی توانید انتظار داشته باشید که آنها توضیح کاملی از دامنه مشکل خود به شما ارائه دهند.کنترلرهای ترافیک هوایی دانش گسترده ای در مورد دامنه خود دارند، اما برای اینکه بتوانید یک مدل بسازید، باید اطلاعات ضروری را استخراج کرده و آن را تعمیم دهید. وقتی شروع به صحبت با آنها می کنید، چیزهای زیادی در مورد پرواز و فرود هواپیماها، هواپیماهایی در هوا و خطر برخورد، هواپیماهایی که در انتظار فرود هستند و غیره خواهید شنید. باید از جایی شروع کنیمکنترل کننده و شما توافق می کنید که هر هواپیما دارای یک فرودگاه حرکت و یک مقصد است. بنابراین همانطور که در شکل زیر نشان داده شده است، یک هواپیما، یک حرکت و یک مقصد داریم.خوب، هواپیما از جایی بلند می شود و در جایی دیگر فرود می آید. اما در هوا چه اتفاقی می افتد؟ چه مسیر پروازی را طی می کند؟ در واقع ما بیشتر به آنچه در هوا متولد می شود علاقه مندیم. کنترل کننده می گوید که به هر هواپیما یک برنامه پرواز اختصاص داده شده است که قرار است کل سفر هوایی را توصیف کند. هنگام شنیدن یک برنامه پرواز، ممکن است در ذهن خود فکر کنید که این مربوط به مسیری است که هواپیما در هنگام پرواز طی کرده است. پس از بحث بیشتر، یک کلمه جالب می شنوید: مسیر. فورا توجه شما را به خود جلب می کند و دلیل خوبی هم دارد. مسیر حاوی مفهوم مهمی از سفر پرواز است. این کاری است که هواپیماها هنگام پرواز انجام می دهند، آنها یک مسیر را دنبال می کنند. بدیهی است که مبدا و مقصد هواپیما نیز نقطه شروع و پایان مسیر است. بنابراین، به جای مرتبط ساختن هواپیما با نقاط عزیمت و مقصد، طبیعی تر به نظر می رسد که آن را با یک مسیر مرتبط کنیم که به نوبه خود با مبدأ و مقصد مربوطه مرتبط است.با صحبت کردن با کنترل کننده در مورد مسیرهایی که هواپیماها دنبال می کنند، متوجه می شوید که در واقع مسیر از بخش های کوچکی تشکیل شده است که در کنار هم نوعی خط کج از مبدأ تا مقصد را تشکیل می دهند. خط قرار است از نقاط ثابت از پیش تعیین شده عبور کند. بنابراین، یک مسیر را می توان به عنوان یک سری اصلاحات متوالی در نظر گرفت. در این مرحله شما دیگر مبدأ و مقصد را به عنوان نقاط پایانی مسیر نمی بینید، بلکه فقط دو مورد دیگر از آن را رفع می کنید. این احتمالاً کاملاً با نحوه مشاهده کنترل کننده آنها متفاوت است، اما یک انتزاع ضروری است که بعداً کمک می کند. تغییرات حاصل بر اساس این اکتشافات عبارتند از:نمودار عنصر دیگری را نشان می دهد، این واقعیت که هر بدون تحرکی، یک نقطه در فضا است که مسیر دنبال می‌شود و به عنوان یک نقطه سه بعدی بیان می شود. اما وقتی با کنترلر صحبت می کنید، متوجه می شوید که او آن را اینطور نمی بیند. در واقع او مسیر را به عنوان پیش بینی پرواز هواپیما بر روی زمین می بیند. ثابت ها فقط نقاطی روی سطح زمین هستند که به طور منحصر به فرد با طول و عرض جغرافیایی تعیین می شوند. بنابراین نمودار صحیح این است:در واقع اینجا چه اتفاقی می افتد؟ شما و کارشناسان حوزه صحبت می کنید، شما در حال تبادل دانش هستید. شما شروع به سوال پرسیدن می کنید و آنها پاسخ می دهند. در حالی که آنها این کار را انجام می دهند، مفاهیم اساسی را از حوزه ترافیک هوایی بیرون می کشند. این مفاهیم ممکن است بدون شفافیت و بی نظم ظاهر شوند، اما با این وجود برای درک دامنه ضروری هستند. شما باید تا حد امکان در مورد دامنه از متخصصان بیاموزید. و با طرح سوالات مناسب و پردازش اطلاعات به روش صحیح، شما و کارشناسان شروع به ترسیم نمای دامنه، یک مدل دامنه خواهید کرد. این دیدگاه نه کامل است و نه صحیح، اما شروعی است که شما به آن نیاز دارید. سعی کنید مفاهیم اساسی دامنه را کشف کنید.این بخش مهمی از طراحی است. معمولاً بحث های طولانی بین معماران یا توسعه دهندگان نرم افزار و کارشناسان حوزه وجود دارد. متخصصان نرم افزار می خواهند دانش را از کارشناسان حوزه استخراج کنند و همچنین باید آن را به شکل مفیدی تبدیل کنند. در برخی موارد، آنها ممکن است بخواهند یک نمونه اولیه ایجاد کنند تا ببینند تا کنون چگونه کار می کند. در حین انجام این کار، ممکن است برخی مشکلات را در مدل یا رویکرد خود پیدا کنند و ممکن است بخواهند مدل را تغییر دهند. ارتباط تنها یک راه نیست، از کارشناسان حوزه تا معمار نرم افزار و بیشتر به توسعه دهندگان. همچنین بازخوردی وجود دارد که به ایجاد یک مدل بهتر و درک واضح تر و صحیح تر از دامنه کمک می کند. کارشناسان دامنه به خوبی حوزه تخصصی خود را می شناسند، اما دانش خود را به روشی خاص سازماندهی و استفاده می کنند، که همیشه بهترین راه برای پیاده سازی در یک سیستم نرم افزاری نیست. ذهن تحلیلی طراح نرم افزار به کشف برخی از مفاهیم کلیدی نرم افزار کمک می کند.«این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است»