به گزارش از وبسایت cncf — ارسال شده در 10 آگوست 2026 توسط Uzochukwu Nweneary | LFX Mentee 🚀
من برای برنامه مربیگری LFX ثبت نام کردم و انتظار داشتم سه ماه را عمدتاً به نگارش اسناد اختصاص دهم. اما چند هفته پس از آغاز، درگیر استقرار مجموعه‌های OpenTelemetry روی نمونه‌های AWS EC2، اشکال‌زدایی مشکلات شبکه بین ماشین‌ها و پی بردن به دلیل عدم ارسال معیارها توسط یک خط لولهٔ ظاهراً سالم شدم.
از نداشتن هرگونه دانش قبلی در زمینهٔ مشاهده‌پذیری به توانایی راه‌اندازی و عیب‌یابی سیستم‌های مشاهده‌پذیر رسیدم. مواجهه با رفتار واقعی سیستم‌ها، تجربه‌ای بی‌نظیر و یکی از مؤثرترین مسیرها برای پیشرفت در مهندسی ابری بود. هیچ‌گاه ضرورت داشتن تخصص کامل برای شروع وجود ندارد؛ کنجکاوی نخستین راه ورود من به دنیای tracing و metrics بود.
سال‌ها مشتاق حضور فعال در یک جامعهٔ متن‌باز بودم و وقتی با هدایت پروژه در زمینهٔ بهبود مستندات Prometheus و OpenTelemetry Interoperability روبه‌رو شدم، آن را فرصت مناسبی برای مشارکت دیدم. انتظار داشتم مشارکت‌هایم عمدتاً به بهبود مستندات محدود بماند؛ مستندسازی بخشی از کار بود، اما خیلی زود دامنهٔ نقش من فراتر رفت.
برای نوشتن مستندات دقیق از سیستم‌های واقعی، لازم بود آن‌ها را خودم مستقر و عیب‌یابی کنم. معماری استقرار من در طول مربیگری چنین بود: برنامه‌های Django روی چند نمونهٔ EC2 اجرا می‌شدند، مجموعه‌های OpenTelemetry کنار هر برنامه مستقر بودند، یک نمونهٔ EC2 مجزا Prometheus را به‌عنوان پشتیبان متریک اجرا می‌کرد و معیارها در قالب Prometheus از همهٔ نمونه‌ها به Prometheus صادر می‌شدند.
هر جزء، یک نقطهٔ احتمالی شکست معرفی می‌کرد. بیشتر خرابی‌ها «بی‌صدا» بودند: از دست رفتن معیارها، شکست خطوط لوله یا سرویس‌هایی که باوجود ظاهراً سالم بودن، کارایی نداشتند. چالش‌های اصلی صرفاً به ابزارهایی مانند OpenTelemetry یا Prometheus محدود نبود؛ مشکلات از تعامل بین اجزا ناشی می‌شدند.
نمونه‌هایی از مشکلات عبارت بودند از: نمونه‌های EC2 که به‌دلیل محدودیت‌های شبکه قادر به برقراری ارتباط نبودند، گردآورنده‌ها که در حال اجرا بودند ولی داده‌ها را صادر نمی‌کردند، خطوط لوله‌ای که بی‌صدا تله‌متری را رها می‌کردند، یا پیکربندی محلی که درست عمل می‌کرد اما استقرار در AWS شکست می‌خورد. دربارهٔ یکی از تجربیات عمیق‌تر اشکال‌زدایی من با جزئیات بیشتر در اینجا نوشته‌ام: [اینجا] ⚙️
یکی از مؤلفه‌های کلیدی مدل مربیگری LFX، استقلال یادگیرنده است. مربیان جهت و بازخورد می‌دهند اما مشکلات را به‌صورت کامل حل نمی‌کنند. راهنمایی‌های تیفانی هرابوسا، آرتور سنس و ویکتوریا ندوکا به‌اندازهٔ کار فنی ارزشمند بود، زیرا آن‌ها استدلال پشت تصمیمات مهندسی را هم توضیح می‌دادند نه صرفاً نتیجهٔ تصمیم را. فهمیدن اینکه چرا یک راه‌حل ترجیح داده می‌شود غالباً از خود راه‌حل مهم‌تر است.
در ابتدا فقدان راهنمایی گام‌به‌گام موجب احساس ناراحتی می‌شد؛ اما با گذشت زمان دریافت کردم که همین استقلال باعث رشد فنی و اعتمادبه‌نفس من شد. ما به‌صورت تیمی مشکلات را بررسی می‌کردیم، رویکردهای مختلف را امتحان می‌کردیم و در عین حال مالکیت کار را به من واگذار می‌کردند. در یکی از مراحل، مربی من دسترسی آزمایشی به یک پلتفرم داد تا یک ایده را تست کنم — با محدودیت‌هایی مانند عدم امکان خودکارسازی استقرار و زمان محدود — که پس از بحث مشترک به راه‌حل موفقی رسیدیم 🤝
بزرگ‌ترین تحول برای من در پایان دوره، نه صرفاً یادگیری یک ابزار خاص، بلکه تغییر در روش درک و تحلیل سیستم‌ها بود. این دیدگاه جدید از یادگیری هر فناوری منفرد ارزشمندتر است و نحوهٔ مواجهه‌ام با مسائل مهندسی را دگرگون کرد. همچنین نسبت به مشاهده‌پذیری دیدی واقع‌بینانه‌تر پیدا کردم: دیدم که این سیستم‌ها باید به‌گونه‌ای طراحی شوند که در برابر شکست‌ها تاب‌آوری داشته باشند.
نتایج ملموس مربیگری نیز قابل توجه بود: بهبودهای من در اسناد OpenTelemetry پذیرفته و ادغام شد، اسناد قابلیت همکاری Prometheus و OpenTelemetry را کامل کردم که از فرمت metrics پرومتئوس استفاده می‌کرد، و یک طرح پیشنهادی برای استقرار سیستم‌های مشاهده‌پذیری در محیط‌های غیر-Kubernetes تهیه کردم.
همچنین اکنون می‌دانم جوامع متن‌باز چگونه سازماندهی می‌شوند و چطور می‌توانم در یک گروه کاری Prometheus یا یک OpenTelemetry SIG مشارکت مؤثر داشته باشم. شاید باارزش‌ترین نتیجه، شبکهٔ حرفه‌ای است که شروع به ساختن آن کرده‌ام؛ از طریق این برنامه با مهندسان باتجربه آشنا شده‌ام و فهمیدم ایجاد ارتباطات واقعی یکی از بهترین مسیرهای رشد در این صنعت است 💡
چرا برنامه‌هایی مانند LFX اهمیت دارند؟ آن‌ها فقط ابزارها را معرفی نمی‌کنند؛ محیط‌های شبیه‌ساز تولید، شکست‌های واقعی سیستم، تفکر معماری، استقلال در حل مسائل و تکرار تجربه در شرایط نزدیک به واقع را فراهم می‌کنند — چیزهایی که به‌سختی فقط از طریق خودآموزی قابل دستیابی‌اند.
نهایی‌ترین نکته این است که مربیگری LFX بیش از قرار گرفتن در معرض ابزارهای بومی ابری برای من داشت: طرز تفکرم دربارهٔ ساخت، اشکال‌زدایی و راه‌اندازی سیستم‌های توزیع‌شده را تغییر داد. اگر به دنبال رشد فراتر از آموزش‌های سطحی و تجربهٔ کار در یک محیط مهندسی واقعی هستید، از شما دعوت می‌کنم برای برنامهٔ مربیگری LFX درخواست دهید و همچنین سایر برنامه‌های پشتیبانی‌شده توسط CNCF را بررسی کنید. اگر در زمینهٔ سیستم‌های بومی ابری فعالیت می‌کنید یا با چالش‌های مشابه روبه‌رو هستید، خوشحال می‌شوم در LinkedIn با من در ارتباط باشید: [link] 😊
