این نوشته خلاصه‌ای از یه مقاله‌ی قدیمیه (لینک) که به دلیل اهمیت اون، مناسب دیدم در موردش صحبت کنیم. بحث اینه که خیلی از ادمین‌های قدیمی شیرپوینت و کسانی که جدیدن درگیر این سیستم شدند، گاهن مجموعه‌ای از اصول و بهروش‌ها رو رعایت نمی‌کنند. همونطور که من هم در پیاده‌سازی‌های خودم کج‌روی‌هایی داشته‌م. پس خوندن این نوشته شاید برای همه‌ی ما که به نحوی با مدیریت شیرپوینت سر و کار داریم واجبه. توجه کنید که این لیست کامل نیست و فقط مسائل فنی رو در نظر میگیره و نگاهی جامع به مشکلات موجود در پیاده‌سازی و مدیریت سیستم شیرپوینت در یه شرکت یا سازمان نداره.
توجه: اگه ادمین شیرپوینت نیستید یا نمی‌خواید باشید و یا علاقه‌ای به مسائل فنی شیرپوینت ندارید، خوندن این مطلب رو ادامه ندید :)
1. نداشتن «شیرپوینت» در عنوان شغلی
شاید این یه «مشکل» بحث‌برانگیز باشه ولی بذارید قبل از همه تکلیفش رو روشن کنیم. کسانی که ادمین سرورها و شبکه هستند، نمیتونند انتظار داشته باشند که یه شبه شیرپوینت رو یاد بگیرند. منظورم اینه که اگه می‌خواهید نقش «ادمین شیرپوینت» رو تو شرکتتون به عهده بگیرید، بهتره از رییستون بخواید، شما رو به آموزش بفرسته. شیرپوینت یه محصول بزرگ و ترسناکه و مثه یه وبسایت معمولی تو IIS نیست. اگه مسئولیت‌های زیادی دارید، شاید باید به دنبال یه کمک باشید و یا روزگار سختی خواهید داشت.
2. ایجاد وب اپلیکیشن‌های زیاد
این یکی بارها گفته شده ولی باز تکرار می‌کنم. به گفته متخصصین هیچ دلیلی وجود نداره که بیشتر از 4 وب اپلیکیشن در شیرپوینت داشته باشید. این چهارتا شامل پرتال یا اینترانت، سایت‌های تیمی، سایت‌ها سرویس یوزر پروفایل (mysites) و دسترسی اینترنتی هستند. پس برای هر مشتری، واحدِ شرکت، پروژه و یا ماژولی که روی شیرپوینت دارید، یه وب اپلیکیشن جدید نسازید.
3. تغییر دستی در IIS
قاعده اینه: «اگه تنظیمی در سنترال ادمین (Central Admin) وجود داره، تغییر رو مستقیم تو IIS انجام ندید». شیرپوینت خودش یه موتور سازنده داره و دوست داره اطلاعات پیکربندی وبسایت رو خودش در دیتابیس پیکربندی (configuration database) ذخیره کنه؛ برای نمونه، لیست وب اپلیکیشن‌ها و وبسایت‌هاشون و نگاشت‌های دسترسی جایگزین (Alternate Access Mappings). اینکه تنظیمات شیرپوینت و IIS یکی باشند، جلوی دردسرها زیادی رو میگیره.
البته مواردی هم هستند که مجبورید تغییراتی رو مستقیمن در IIS ایجاد کنید؛ برای نمونه، تنظیمات سرتیفیکت‌های SSL.
4. استفاده نکردن از فریم‌ورک راهکارهای شیرپوینت (SharePoint solutions framework)
این یکی محل تلاقی ادمین و توسعه است. قانون راحتیه: اگه دولوپر یه سری فایل داد که WSP نیستند، اونها رو در سرورها دیپلوی نکنید.
تغییر دستی در فولدر روت شیرپوینت منجر به ورود به فضایی پر از دردسر و عدم پایداری میشه، مخصوصن وقتی به دنبال افزایش تعداد سرورهای فارم باشید. این فولدر شامل فیچرها، الگوها، برندینگ و راهکارهای سندباکس است. جلوی تغییرات دستی در شیرپوینت رو به هر قیمتی بگیرید.
5. نصب سرور در حالت تکی (standalone server)
خیلی از ادمین‌های تازه‌کار شیرپوینت این اشتباه رو می‌کنند و در دامِ نصابِ (ویزارد) شیرپوینت میوفتند که به شکل خنده‌داری، حالت نصب تکی (standalone) رو پیشنهاد میده. در این حالت، شما قابلیت مقیاس‌پذیری خیلی محدودی دارید و وقتی بخواید فارم رو آپگرید کنید، کار به شکل غیر قابل اجتنابی سخت میشه. این گزینه رو در موقع نصب انتخاب نکنید و به تبعاتش فکر کنید.
6. استفاده از تنظیمات پیشفرضِ رشدِ دیتابیس
در خیلی از موارد، ادمین‌ها از رابط کاربری برای ایجاد دیتابیس‌های کانتنت (content database) استفاده می‌کنند. هر چند این روش هم جواب میده ولی عملکرد SQL محدود به تنظیمات قدیمیِ پیشفرضِ رشد دیتابیس میشه. در نظر بگیرید که اگه تنظیم پیشفرض رشد مثلن 1 مگابایت باشه، با بارگزاری یه فایل 10 مگابایتی باعث میشه که دیتابیس بخواد 10 بار بزرگ بشه.
شیرپوینت برای دانلود بهینه شده ولی برای آپلود نه. تنظیمات SQL رو بر اساس شرایط وب اپلیکیشن‌های خودتون تغییر بدید.
7. مستند نکردن پیکربندی فارم
وقتی دچار یه بحران می‌شوید و یا وقتی می‌خواهید تغییری در تنظیمات فارم انجام بدهید، باید آنچه در حال حاضر هست رو در جایی نوشته باشید. به این سند در چنین مواقعی نیازه و همیشه هم باید با توجه به آخرین تغییرات در پیکربندی به روز بشه.
گرفتن بکاپ از تنظیمات و همچنین دیتابیس پیکربندی (configuration database) هم پیشنهاد میشه.
8. تغییر دستی دیتابیس‌های شیرپوینت برای درست کردن چیزی
تغییرات دستی در دیتابیس‌های شیرپوینت پشتیبانی نمیشه و باعث خرابکاری‌هایی میشه. قانون ساده‌ایه که گاهن بد فهمیده شده و یا در نظر گرفته نمیشه. تنها استثنا دیتابیس لاگ (logging database) است که اطلاعات فارم و پیکربندی هم در اون نیست. همیشه از object model شیرپوینت برای انجام تغییرات استفاده کنید.
9. باور به اینکه پاورشل فقط برای دولوپرهاست
پاورشل شیرپوینت (PowerShell) سالهاست که معرفی شده و شاید اولش یه ذره ترسناک به نظر بیاد ولی ابزارِ ادمینیِ خوبیه. میتونید از اون برای چک کردن سریع لاگ‌ها و کارهای دیگه‌ی بسیاری استفاده کنید. اگه کمی وقت برای کار با پاورشل بگذارید، باهاش آشنا میشید و ازش لذت می‌برید. توجه کنید که پاورشل گاهن کارهایی میتونه انجام بده که از طریق رابط کاربری شیرپوینت (در سایت سنترال ادمین) قابل انجام نیست.
10. بی‌توجهی به پیشنهادهای مربوط به طرح‌ریزی ظرفیت شیرپوینت
هر بار با افرادی مواجه میشم که می‌پرسند: «یه دیتابیس خیلی گیگابایتی داریم، چکارش کنیم؟». به نظر میاد محدودیت‌های فنی مربوط به ظرفیت رو معمولن زیر فرش قایم می‌کنند. قبل از اینکه شروع به پیاده‌سازی شیرپوینت کنید، حتمن سند مربوط به طرح‌ریزی ظرفیت (capacity planning) مربوط به نسخه‌ی شیرپوینت خودتون رو ببینید. محدودیت‌هایی مثل حجم فایل، تعداد فایل در مخزن (Library)، حجم دیتابیس کانتنت و .. وجود داره. شاید گاهی مجبور بشید برای رسیدن به عملکرد و سرعت بیشتر، یه دیتابیس کانتنت رو به چندتا تقسیم کنید.
امیدوارم این نوشته، به درک بهترِ شکلِ رفتار با شیرپوینت و همچنین در نظر گرفتن اصولی برای مدیریت بهینه‌ی فارم شیرپوینت کمک کرده باشه.
