سلام دوستان
📊 چرا با وجود صرف هزینه‌های زیاد برای ساخت گزارش‌ها، بسیاری از آن‌ها در عمل استفاده نمی‌شوند؟
در یکی از پروژه‌هایی که روی آن کار می‌کردم، کنار یکی از کاربران سازمان نشستم تا ببینم گزارش‌ها را چطور استفاده می‌کند.
اتفاق جالبی افتاد.
کاربر گزارش را باز کرد، چند ثانیه به آن نگاه کرد و بعد... فایل Excel شخصی خودش را باز کرد.
شروع کرد اطلاعات گزارش را یکی‌یکی وارد Excel کند و تحلیلش را آنجا ادامه داد.
همان لحظه یک سؤال در ذهنم شکل گرفت...
اگر سازمان‌ها برای طراحی گزارش‌ها زمان، انرژی و هزینه زیادی صرف می‌کنند، چرا بسیاری از کاربران در نهایت دوباره به Excel برمی‌گردند؟ 🤔
آیا مشکل از کیفیت گزارش‌هاست؟
یا گزارش‌ها بر اساس نیاز واقعی کاربران طراحی نمی‌شوند؟
یا شاید اصلاً مسئله چیز دیگری است...
من فعلاً قصد ندارم به این سؤال پاسخ بدهم.
دوست دارم از تجربه شما یاد بگیرم. 🌱
اگر در سازمانتان گزارش‌هایی وجود دارد که کمتر از آنچه انتظار می‌رفت مورد استفاده قرار می‌گیرند، به نظر شما مهم‌ترین دلیل چیست؟
👤 فرقی نمی‌کند مدیرعامل باشید، مدیر واحد، کارشناس، تحلیلگر داده، DBA یا توسعه‌دهنده BI.
تجربه شما می‌تواند به شناخت یک الگوی مشترک در سازمان‌ها کمک کند.
💬 مشتاقم نظرات و تجربه‌های واقعی شما را بخوانم.
━━━━━━━━━━━━━━
🔍 Organizational Patterns
من در حال مطالعه الگوهای مشترک در سازمان‌ها هستم؛ الگوهایی که بر نحوه تصمیم‌گیری، همکاری تیم‌ها و خلق ارزش اثر می‌گذارند.
اگر تجربه مشابهی دارید، خوشحال می‌شوم آن را در بخش نظرات با من و دیگران به اشتراک بگذارید.

🧩 Organizational Pattern #001

سلام
📊 چند روز پیش درباره این سؤال نوشتم که چرا بسیاری از گزارش‌ها و داشبوردهای سازمانی استفاده نمی‌شوند.
صادقانه بگویم، انتظار داشتم بیشتر درباره ابزارها، تکنولوژی یا نحوه طراحی گزارش صحبت شود.
اما چیزی که از دل گفتگوها بیرون آمد، برای خودم هم جالب بود.
تقریباً هرکسی از زاویه تجربه خودش به موضوع نگاه می‌کرد:
🔹 یکی می‌گفت باید کنار کاربر نشست و رفتار واقعی او را دید.
🔹 دیگری می‌گفت همیشه چنین فرصتی وجود ندارد و محدودیت‌های سازمانی را هم باید در نظر گرفت.
🔹 فردی روی آموزش کاربران و نقش Master Trainer تأکید داشت.
🔹 عده‌ای معتقد بودند مشکل اصلی، بلوغ پایین سازمان‌ها در استفاده از داده است.
نکته‌ای که برای من پررنگ شد این بود که ما معمولاً تصور می‌کنیم همه درباره یک مسئله صحبت می‌کنیم؛ در حالی که هرکدام از ما در حال توصیف بخشی از یک سیستم بزرگ‌تر هستیم.
شاید مسئله اصلی «گزارش» نباشد.
شاید مسئله، فاصله‌ای باشد که بین نگاه توسعه‌دهنده، مدیر، کاربر و تصمیم‌گیرنده وجود دارد.
هرکدام واقعیت را از زاویه خودش می‌بیند و اگر این زاویه‌ها به هم متصل نشوند، حتی بهترین نرم‌افزارها هم نمی‌توانند ارزش واقعی ایجاد کنند.
برای من، این گفتگو فقط درباره گزارش نبود؛ بلکه شروع یک سؤال بزرگ‌تر بود:

"❓ به نظر شما، بزرگ‌ترین شکاف بین تیم‌های فنی و کسب‌وکار در سازمان‌ها چیست؟ "

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

🧩 Organizational Pattern #002

چند روز پیش روی یکی از دیتابیس‌ها با یک سناریوی جالب روبه‌رو شدم که شاید برای خیلی از DBAها آشنا باشد.

کاربران از کندی شدید سیستم شکایت داشتند.
⏱️ زمان اجرای بعضی Updateها به ۷ تا ۸ ثانیه رسیده بود.
اولین چیزی که در Wait Stats جلب توجه می‌کرد، مقدار بالای LCK_M_U بود.
اگر فقط به همین Wait نگاه کنیم، احتمالاً اولین حدس این است که مشکل از Locking، Isolation Level یا یک Query بد است.
اما وقتی Blocking Chain را بررسی کردم، داستان چیز دیگری بود...
تقریباً تمام Sessionها پشت یک Session Block شده بودند.
و آن Session فقط یک Wait قابل توجه داشت:

🔴 WRITELOG
همان‌جا مشخص شد که احتمالاً مشکل اصلی Lock نیست.
مشکل این بود که Commit تراکنش‌ها دیر انجام می‌شد.
در SQL Server، در حالت عادی (Full Durability)، زمانی که دستور COMMIT اجرا می‌شود، باید رکوردهای Transaction Log مربوط به آن تراکنش روی فایل Log (LDF) پایدار (Harden) شوند. تا زمانی که Commit کامل نشود، Lockهای آن تراکنش نیز آزاد نمی‌شوند.
بنابراین اگر به هر دلیلی Flush شدن Transaction Log کند باشد:
یک اینکه Commit دیرتر کامل می‌شود.
دوم اینکه Lockها مدت بیشتری نگه داشته می‌شوند.
سوم اینکه Sessionهای دیگر پشت آن منتظر می‌مانند.
و نتیجه چیزی است که ما به شکل LCK_M_U و Blocking مشاهده می‌کنیم.
برای اطمینان از فرضیه، روی Database گزینه Delayed Durability را در حالت ALLOWED فعال کردم.
نتیجه واقعاً جالب بود.

🚀 زمان Updateها از حدود ۷ تا ۸ ثانیه به کمتر از ۱۰۰ میلی‌ثانیه رسید.
تقریباً تمام Blockingها از بین رفتند.
این تجربه دوباره یک نکته مهم را برایم یادآوری کرد:
💡 همیشه بزرگ‌ترین Wait الزاماً ریشه مشکل نیست.
گاهی چیزی که می‌بینیم فقط اثر دومینویی یک Bottleneck دیگر است.
در این سناریو، LCK_M_U علت نبود؛ پیامد بود.
ریشه اصلی، WRITELOG بود که باعث می‌شد Commitها دیرتر کامل شوند و در نتیجه Lockها نیز دیرتر آزاد شوند.
البته یک نکته مهم را هم نباید فراموش کرد.

توجه : Delayed Durability یک راهکار بدون هزینه نیست.
وقتی آن را فعال می‌کنید، SQL Server ممکن است بعضی Commitها را قبل از Flush شدن Log به دیسک به Application برگرداند. اگر قبل از Flush، Crash یا قطع برق اتفاق بیفتد، آخرین Transactionهای Commit شده اما هنوز Flush نشده ممکن است از بین بروند.
به همین دلیل، این قابلیت باید با توجه به نیازهای کسب‌وکار و میزان ریسک قابل قبول استفاده شود؛ نه صرفاً برای کاهش Waitها.

❓برای شما هم پیش آمده که یک Wait مثل LCK_M_U فقط یک علامت باشد و بعد از بررسی دقیق‌تر متوجه شوید ریشه اصلی مشکل جای دیگری بوده است؟

سلام دوستان عزیزم.

👨‍💻 یکی از سوال‌هایی که همیشه ازم می‌پرسن اینه که:
«توی مصاحبه فنی از افراد چی می‌پرسی؟» 🤔
پیرو چند پست قبلی که درباره مصاحبه نوشتم، بد نیست اینم بگم که من معمولا افراد رو از نظر سطح دانش به چهار دسته تقسیم می‌کنم:
🔹 کارآموز
🔹 مبتدی
🔹 متوسط
🔹 حرفه‌ای
و جالبه که نوع سوالاتم برای هر کدوم کاملا فرق می‌کنه.
مثلا اگر کسی بگه:
«من Senior هستم» 😎
راستش اولین چیزی که برام مهمه این نیست که چند تا Query از حفظ بلده یا چقدر سریع کد می‌نویسه.
اتفاقا خیلی از مصاحبه‌ها از همون دقیقه اول میگن:
"این مسئله رو حل کن، کدش رو بنویس."
این روش بد نیست... ولی من بیشتر دوست دارم قبل از اینکه حتی به کد برسیم، بفهمم اون آدم دیتابیس رو واقعا درک کرده یا فقط باهاش کار کرده.
مثلا ازش می‌پرسم:
🟢وقتی SQL Server Engine این Query رو اجرا میکنه چه رفتاری داره؟
🟢 اثری که این کد روی Performance میذاره چیه؟
🟢 اگر سیستم کند بشه، از کجا شروع می‌کنی مشکل رو پیدا کنی؟
🟢 وقتی یک نیاز از سمت کاربر میاد، چطور اون رو تبدیل به طراحی دیتابیس و پیاده‌سازی می‌کنی؟
🟢 اگر بین چند راه‌حل انتخاب داشته باشی، چرا یکی رو انتخاب می‌کنی؟
برای من طرز فکر آدم‌ها از خود جواب‌ها مهم‌تره.
اما وقتی طرف در سطح مبتدی یا متوسط باشه، طبیعتا انتظارم فرق می‌کنه.
اونجا بیشتر میرم سراغ مفاهیم پایه:
✅ این دستور دقیقا چه کاری انجام میده؟
✅ کجا باید ازش استفاده کرد؟
✅ تفاوتش با دستور مشابهش چیه؟
✅ اگر بخوای این مسئله رو حل کنی، اولین قدمت چیه؟
و یکی از سوال‌های مورد علاقه‌م همیشه اینه:
💡 «جذاب‌ترین چالشی که تا امروز حل کردی چی بوده؟»
نه برای اینکه جواب درست یا غلط داره...
برای اینکه از روی نحوه تعریف کردنش میشه فهمید:
چقدر عمیق فکر می‌کنه.
چطور مسئله رو تحلیل می‌کنه.
از چه ابزارهایی استفاده کرده.
و مهم‌تر از همه... آیا از حل کردن مسئله لذت می‌بره یا فقط دنبال بستن تیکت بوده؟ 😄
به نظر من، گاهی با همین چند سوال میشه شناختی از یک مهندس به دست آورد که شاید با یک ساعت کدنویسی هم به دست نیاد.
❓حالا دوست دارم نظر شما رو هم بدونم.
اگر شما مصاحبه‌کننده باشید، اولین سوالی که از یک Database Developer یا Data Engineer می‌پرسید چیه؟

سلام دوستان عزیزم

۵۰۰ دوره آموزشی مکتب‌خونه رایگان شد.

دوره آموزش پایگاه داده بنده نیز در لیست دوره ها قرار داره.

فراهم‌کردن دسترسی گسترده‌تر به آموزش باکیفیت، یکی از اهداف اصلی مکتب‌خونه است. در ادامه این مسیر، در طرح «ایرانِ ‌ماهر» ۵۰۰ دوره آموزشی تا ۸ شهریور رایگان شده است.

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

دوره‌های رایگان ایران ‌ماهر موضوعات متنوعی را پوشش می‌دهند؛ از برنامه‌نویسی، هوش مصنوعی و آی‌تی تا زبان، مدیریت، بازاریابی، مالی، حسابداری و مهارت‌های شغلی.

برای استفاده از این فرصت، از طریق لینک زیر دوره مورد نظرتان را انتخاب کنید و با وارد کردن کد IRANMAHER در مرحله پرداخت، آن را با تخفیف ۱۰۰٪ دریافت کنید.

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

https://land.maktabkhooneh.org/iranmaher/?utm_source=linkedin&utm_medium=social&utm_campaign=iranmaher-linkedin-social-mk