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

اگر این کتاب را می‌خوانید زیرا از قبل در مهندسی پلتفرم مشغول به کار هستید و به دنبال نکاتی برای انجام بهتر آن می‌گردید، ممکن است وسوسه شوید که از این دو فصل اول صرف نظر کنید. به هر حال، آنها امیدواریم آنچه را که از قبل می‌دانید به شما بگویند: چرا باید پلتفرم بسازید و ستون‌های اصلی که «چیستی» مهندسی پلتفرم را تشکیل می‌دهند. با این حال، ما شما را تشویق می‌کنیم که با ما همراه باشید، زیرا بسیاری از مردم مانند شما آن را درک نمی‌کنند. این فصل‌ها به شما کمک می‌کنند تا مهندسی پلتفرم را برای همکاران، رئیس و تیم خود توضیح دهید، زمانی که با سوالاتی مانند: انگیزه انجام آن چیست؟ چه مشکلاتی را می‌توانیم با مهندسی پلتفرم حل کنیم؟ و تیم ما برای انجام خوب آن باید روی چه چیزی تمرکز کند؟

ما این کتاب را با «چرا» شروع می‌کنیم، نه تنها برای بیان دلایلی که فکر می‌کنیم باید به ساخت پلتفرم‌ها اهمیت دهید، بلکه برای به اشتراک گذاشتن انگیزه خود برای نوشتن کتاب. ما مشتاق حل این مشکلات هستیم و می‌خواهیم تعداد بیشتری از شما را الهام‌بخش حل آنها ببینیم. پلتفرم‌ها از دل مبارزات مهندسی نرم‌افزار مدرن در مقیاس بزرگ متولد می‌شوند: خواسته‌های باورنکردنی که بر تیم‌ها تحمیل می‌کنیم تا یک اکوسیستم وسیع را که در حال تغییر سریع است، بدون فدا کردن در دسترس بودن (Availability) و عملکرد برنامه‌هایشان، مدیریت کنند. این به معنای آن نیست که مهندسی پلتفرم می‌تواند حل کند...

در بخش اول، درباره «چرا» و «چیستی» مهندسی پلتفرم صحبت کردیم و امیدواریم اکثر شما را به ارزش انجام بیشتر آن در شرکتتان متقاعد کرده باشیم. اما مطمئنیم که برخی از شما هنوز شک دارید، و می‌پرسید که آیا این فقط یک نام‌گذاری مجدد از مهندسی زیرساخت، دِوآپس (DevOps) و SRE نیست، جایی که تیم قول می‌دهد محصولات مشتری‌محور توسعه دهد اما در واقع فقط بر روی عملیات مجموعه‌ای از سیستم‌های OSS و فروشنده نامرتبط تمرکز می‌کند. یا ممکن است به دلایل دیگری شک داشته باشید؛ شاید تجربه رهبران جدیدی را داشته‌اید که از پس‌زمینه مهندسی برنامه/محصول آمده‌اند و فکر می‌کنند می‌توانند تمام مشکلات سخت پلتفرم‌های مقیاس‌پذیر را با نرم‌افزار جدید حل کنند، اما هیچ درک عمیقی از آنچه در عملیات سیستم‌های حیاتی و پیچیده دخیل است، ندارند.

ما نیز این تجربیات را پشت سر گذاشته‌ایم و هدف ما برای بخش دوم این است که به شما بیاموزیم چگونه از این نتایج اجتناب کنید و از تخم بیرون بیایید تا در نهایت پرواز کنید. برای انجام این کار، هشت فصل بعدی – بخش عمده کتاب – را به صحبت درباره «چگونگی» سازمان‌های بزرگ مهندسی پلتفرم اختصاص خواهیم داد. با بحث در مورد شروع کار، انتخاب افراد مناسب، اتخاذ تفکر محصول و عملیات موفقیت‌آمیز پلتفرم خود شروع خواهیم کرد. سپس به کارهای پیچیده‌تر برنامه‌ریزی، بازمعماری (Rearchitecting)، ...

یک تیم پلتفرم که با تمام توان خود کار می‌کند، اغلب ممکن است به نظر برسد که پیشرفت کمی دارد. شما برخی از سیستم‌ها را به حالت پایدار می‌رسانید، که تیم شما را قادر می‌سازد تا روی حوزه‌های دیگر تمرکز کند، اما تنها یک یا دو سال بعد، زمانی که سیستم‌ها منسوخ شده و دیگر به شرکت خدمت نمی‌کنند، دوباره به عقب کشیده می‌شوید. مسیرهای همواری که ۸۰ درصد را راضی می‌کنند، همچنان ۲۰ درصد دیگر را با نارضایتی از عدم رسیدگی به نیازهایشان رها می‌کنند. شما تیم متعادل و عالی را استخدام می‌کنید، اما تنها با یک بحران بودجه مواجه می‌شوید که شما را مجبور به اخراج برخی می‌کند، یا یک چرخه رشد که افراد عالی را به سمت فرصت‌های بهتر سوق می‌دهد. علاوه بر این، حتی زمانی که در حال پیشرفت هستید، ارائه ارزش کند است؛ زمان می‌برد تا یک محصول با کیفیت بالا بسازید، زمان می‌برد تا مشتریان را به استفاده از آن متقاعد کنید، و زمان می‌برد تا همه را مهاجرت دهید.

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