بیشتر مطالبی که درباره شیرپوینت می‌خوانید، از زاویه مدیران یا مشاوران نوشته شده است: مزایا، قابلیت‌ها، نمودارهای زیبا. این نوشته متفاوت است. من می‌خواهم از جایی بگویم که مدیر سیستم می‌نشیند؛ جایی که کار با نصب تمام نمی‌شود و اولین تماس «سایت کند شده» معمولاً درست ساعتی می‌آید که تازه از محل کار بیرون رفته‌اید.

اگر تصمیم گرفته‌اید سرور شیرپوینت را در سازمان خودتان مستقر کنید یا این مسئولیت به شما سپرده شده، این یادداشت را مثل حرف‌های یک همکار قدیمی‌تر بخوانید. قرار نیست همه جزئیات فنی را بازگو کنم؛ مستندات رسمی این کار را بهتر انجام می‌دهند. می‌خواهم درباره چیزهایی بنویسم که معمولاً در مستندات نیست و فقط با ریشه‌یابی چند اتفاق ناخوشایند یاد گرفته می‌شود.

باور کنید یا نه، نصب شیرپوینت دشوارترین بخش کار نیست. ابزار پیکربندی، Prerequisite Installer و Configuration Wizard دست شما را می‌گیرند و کار را جلو می‌برند. مشکل اینجاست که همین سادگی ظاهری، آدم را به سمت تصمیم‌های عجولانه می‌برد. معمولاً با پذیرفتن مقادیر پیش‌فرض، نام دیتابیس‌هایی با پسوند GUID و حساب‌هایی با دسترسی بیش از حد، کار را جلو می‌بریم و بعد در مرحله نگهداری تاوانش را می‌دهیم.

چند تصمیم کوچک در همان ابتدا تفاوت بزرگی می‌سازند. نام دیتابیس‌ها را معنادار انتخاب کنید و تنظیمات پایگاه داده پیکربندی را از قبل مستند کنید. Alias برای SQL تعریف کنید تا اگر روزی بخواهید دیتابیس را به سرور دیگری ببرید، نیازی به دستکاری فارم نباشد. حساب‌های سرویس را جدا کنید: یکی برای Farm، یکی برای Application Pool مربوط به هر وب‌اپلیکیشن، یکی برای جستجو و یکی برای دسترسی به محتوا. و مهم‌تر از همه، مراحل نصب را در یک سند خودتان بنویسید. اگر سه سال بعد مجبور شدید فارم را از نو بسازید، همین سند نجات‌تان می‌دهد.

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

شایع‌ترین شکایت بعد از چند ماه استفاده، کندی است. ریشه کندی به‌ندرت در خود نرم‌افزار است؛ بیشتر اوقات به یکی از چند منبع برمی‌گردد. اول از همه SQL Server. شیرپوینت تقریباً هر چیزی را در دیتابیس نگه می‌دارد و اگر دیسک‌های SQL کند، حافظه ناکافی یا ایندکس‌های فرسوده داشته باشید، کل سیستم احساس کندی می‌کند. نگهداری منظم دیتابیس، یعنی بازسازی ایندکس‌ها و به‌روزرسانی آمار، کاری است که بسیاری از تیم‌ها فراموش می‌کنند.

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

سوم، صفحات سنگین. گاهی مقصر سرور نیست؛ یک صفحه با ده وب‌پارت و چندین لیست بزرگ بدون ایندکس، می‌تواند کل تجربه کاربر را خراب کند. یکی از بدترین موارد را در سازمانی دیدم که یک لیست با صدها هزار آیتم و بدون ستون ایندکس‌شده داشتند و هر بار که کسی آن را باز می‌کرد، فارم دچار آستانه محدودیت لیست می‌شد. راه‌حل نه خرید سرور قوی‌تر، بلکه بازطراحی نمایش‌ها و ایندکس‌گذاری درست بود.

چهارم، شبکه و پروکسی. گاهی کاربران یک شعبه خاص شکایت دارند و بقیه مشکلی ندارند. قبل از دست‌بردن در فارم، مسیر شبکه، تنظیمات DNS و احراز هویت Kerberos یا NTLM را بررسی کنید. چندین بار پیش آمد که مشکل «کندی شیرپوینت» در واقع یک رکورد DNS اشتباه یا مشکل SPN بود.

اگر می‌خواهم یک بخش از این نوشته را به عنوان مهم‌ترین انتخاب کنم، همین بخش است. مدیریت مجوزها در شیرپوینت مثل مدیریت یک انبار قدیمی است؛ اگر از روز اول نظم نداشته باشد، بعد هیچ‌کس جرأت دست زدن به آن را ندارد.

چیزی که معمولاً رخ می‌دهد این است: مالک یک سایت، برای یک فایل مهم، دسترسی ویژه به یک همکار می‌دهد. چند ماه بعد، دسترسی دیگری برای مدیر محترم و بعد برای یک مشاور بیرونی. بعد از یک سال، در همان کتابخانه صدها مجوز منحصربه‌فرد وجود دارد. حالا کسی می‌پرسد «چه کسانی به این سند دسترسی دارند؟» و پاسخ، یک گزارش دو ساعته است.

راه جلوگیری ساده است ولی نیازمند انضباط. دسترسی‌ها را همیشه از طریق گروه‌ها بدهید. برای هر سایت، سه گروه استاندارد بسازید: بازدیدکننده، عضو و مالک. به مالکان سایت آموزش بدهید که مجوز یکتا را فقط وقتی لازم است تعریف کنند. و هر شش ماه یک بار، گزارش مجوزهای منحصربه‌فرد را بگیرید و بررسی کنید. این کار کمی خسته‌کننده است ولی بسیار ارزان‌تر از یک حادثه افشای اطلاعات است.

درباره وصله‌ها دو مکتب فکری وجود دارد و هر دو خطرناک‌اند. مکتب اول می‌گوید هر چه منتشر شد فوراً نصب کن. مکتب دوم می‌گوید تا چیزی خراب نشده دست نزن. مکتب اول ریسک ناسازگاری دارد و مکتب دوم ریسک امنیتی. راه میانه، یک چرخه منظم است.

پیشنهاد من این است: اطلاعیه‌های امنیتی را دنبال کنید، هر ماه یا هر فصل یک پنجره نگهداری مشخص با کاربران هماهنگ کنید، به‌روزرسانی را اول روی محیط آزمایشی اجرا کنید، از دیتابیس‌ها و پیکربندی نسخه پشتیبان بگیرید و بعد روی محیط واقعی اعمال کنید. به‌روزرسانی‌های شیرپوینت به‌خصوص در فارم‌های چندسروره نیاز به ترتیب درست دارند و Upgrade دیتابیس‌ها ممکن است زمان‌بر باشد؛ پس هرگز آن را در آخرین ساعت کاری پنجشنبه شروع نکنید.

اگر هنوز روی نسخه‌های ۲۰۱۶ یا ۲۰۱۹ هستید، طبق چرخه اعلام‌شده توسط مایکروسافت، پشتیبانی رسمی این نسخه‌ها به پایان رسیده یا خیلی نزدیک است. ماندن روی نسخه‌ای که دیگر وصله امنیتی دریافت نمی‌کند، قماری است که بهتر است در آن شرکت نکنید. نسخه Subscription Edition مسیر ارتقای رسمی است و هرچه زودتر برنامه‌ریزی کنید، با فشار کمتری انجامش می‌دهید.

فارم بدون پایش مثل ماشین بدون پنل کیلومتر است؛ تا زمانی که از کار نیفتاده نمی‌دانید چه حالی دارد. خوشبختانه برای شروع لازم نیست ابزار پیچیده بخرید. چند شاخص اصلی را دنبال کنید: فضای خالی دیسک سرورها و SQL، میزان مصرف حافظه و پردازنده، زمان پاسخ صفحه اصلی، وضعیت سرویس‌های جستجو و Timer Service، و خطاهای ثبت‌شده در ULS Log و Event Viewer.

گزارش‌های سلامت داخلی خود شیرپوینت (Health Analyzer) هم منبع خوبی است. بسیاری از مدیران هشدارهای آن را نادیده می‌گیرند چون زیادند. ولی اگر هفته‌ای یک بار مرورشان کنید، متوجه می‌شوید که چقدر از آن‌ها ریشه یکسانی دارند و با یک اصلاح بر طرف می‌شوند. هشدارهای مهم را به ایمیل یا پیام‌رسان داخلی تیم متصل کنید تا قبل از این‌که کاربر شکایت کند، شما خبردار شوید.

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

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

یک آزمایش ساده پیشنهاد می‌کنم: از سه نفر از همکاران غیر فنی بخواهید یک سند را آپلود کنند، فراداده فارسی برایش ثبت کنند، با کلمه‌ای از وسط متن جستجویش کنند و تاریخ ایجاد آن را بخوانند. نظر آن‌ها از هر چک‌لیست فنی ارزشمندتر است.

گردش‌کارهای کهنه در محیط‌های سازمانی زیاد دیده می‌شوند. گردش‌کارهای قدیمی SharePoint Designer، به‌خصوص نسخه ۲۰۱۰، دیگر مسیر توسعه‌ای ندارند و اگر قرار است فرایند جدیدی بسازید، بهتر است ابزارهای جدیدتر و راه‌حل‌های پشتیبانی‌شده را بررسی کنید. نکته مهم این است که هر فرایند خودکار را قبل از ساختن، روی کاغذ توضیح دهید: چه کسی چه چیزی را تأیید می‌کند، اگر تأییدکننده مرخصی باشد چه می‌شود، و در صورت رد شدن، کار به کجا برمی‌گردد.

تجربه من این است که ۸۰ درصد شکست‌های اتوماسیون، فنی نیستند؛ سازمانی‌اند. فرایندی که روی کاغذ مبهم است، در سیستم هم مبهم خواهد بود. پیش از هر چیز، فرایند را ساده کنید، بعد خودکارش کنید.

بارها دیده‌ام که یک سازمان با افتخار می‌گوید هر شب بکاپ می‌گیریم. وقتی می‌پرسم آخرین بار کی بازیابی کردید، سکوت می‌شود. بکاپ بدون آزمون بازیابی، فقط یک امید است. بازیابی شیرپوینت چند لایه دارد: دیتابیس‌های محتوا، دیتابیس‌های سرویس، پیکربندی فارم، سفارشی‌سازی‌ها و گواهی‌ها. اگر فقط یکی از این‌ها را نگه داشته باشید، در روز حادثه با پازلی ناقص روبه‌رو می‌شوید.

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

بهترین فارم دنیا بدون کاربر آموزش‌دیده، فقط یک مصرف‌کننده برق است. کاربران باید بدانند چرا باید سند را در شیرپوینت بگذارند، نه در ایمیل؛ چرا ویرایش همزمان بهتر از ارسال نسخه‌های مختلف است و چطور لینک سند را به جای خود فایل به اشتراک بگذارند. آموزش کوتاه، تصویری و مبتنی بر مسئله‌های واقعی کار هر واحد، بسیار مؤثرتر از دوره‌های طولانی عمومی است.

یک روش که برای من جواب داده، معرفی «قهرمان‌های شیرپوینت» در هر واحد است؛ یک نفر علاقه‌مند که اولین مرجع هم‌تیمی‌هایش می‌شود. این افراد بار پشتیبانی شما را کم می‌کنند و بازخورد دقیقی از میدان می‌آورند.

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

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

همه مدیران سیستم دوست دارند همه چیز را خودشان حل کنند و این روحیه ارزشمند است. اما برخی موقعیت‌ها هست که عقل می‌گوید کمک بگیرید: فارم‌های چندسروره با نیاز دسترس‌پذیری بالا، مهاجرت‌های حجیم، عیب‌هایی که سه روز است حل نمی‌شوند و پروژه‌های توسعه سفارشی. نیاز به کمک گرفتن نشانه ضعف نیست؛ نشانه مدیریت ریسک است.

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

اگر امروز مدیریت یک فارم شیرپوینت به شما سپرده شده، پیشنهاد می‌کنم هفته اول را صرف این کارها کنید:

• نقشه فارم را روی کاغذ بکشید: چند سرور، چه نقشی، چه نسخه‌ای و چه وابستگی‌هایی.
• آخرین نسخه پشتیبان را پیدا کنید و ببینید آخرین بار کی بازیابی آزمایش شده است.
• فهرست حساب‌های سرویس و سطح دسترسی هر کدام را مرور کنید.
• سطح به‌روزرسانی فعلی را بررسی کنید و با آخرین نسخه پایدار مقایسه کنید.
• گزارش Health Analyzer را بخوانید و موارد مهم را اولویت‌بندی کنید.
• با سه نفر از کاربران اصلی صحبت کنید و بپرسید بیشتر از همه از چه چیزی ناراضی‌اند.
• مشخص کنید در شرایط اضطراری چه کسی و چگونه پاسخ‌گوست.

این فهرست، شاید جذاب نباشد ولی بیشتر ریسک‌های بزرگ را در همان هفته اول آشکار می‌کند.

مدیریت سرور شیرپوینت، ترکیبی از فنی‌گری، انضباط و ارتباط با آدم‌هاست. نرم‌افزار قدرتمندی است، اما قدرتش فقط در دست کسانی خودش را نشان می‌دهد که به آن رسیدگی می‌کنند. مستند کنید، پایش کنید، آزمایش کنید و بدون ترس از پرسیدن، از دیگران کمک بگیرید.

و اگر فقط یک چیز از این مقاله به یاد داشته باشید، این باشد: بیشتر بحران‌های شیرپوینت، حاصل اتفاق‌های ناگهانی نیستند؛ نتیجه تصمیم‌های کوچکی هستند که ماه‌ها پیش گرفته شده و کسی به آن‌ها برنگشته است. با نگاه منظم و صبور، می‌توانید فارمی بسازید که نه‌تنها کار می‌کند، بلکه وقتی صبح به محل کار می‌رسید، اولین چیزی که به آن فکر می‌کنید نباشد.