رفتن به محتوا
IROSG.
EN
آشنایی با مشاهیر

لیز رایس؛ از یک درخواست ادغام تا راهبری فنی CNCF و آموزش eBPF

روایتی مستند از مسیر حرفه‌ای Liz Rice؛ از مهندسی شبکه و مشارکت متن‌باز تا هم‌ریاست KubeCon، ریاست CNCF TOC و نقش او در محتوای Cilium، Tetragon و eBPF در رویداد رسمی Isovalent در سال ۲۰۲۶، با تفکیک دقیق عنوان‌های شغلی در دو مقطع.

نشان eBee رویداد KubeCon + CloudNativeCon Japan ۲۰۲۶ در صفحهٔ رسمی Isovalent

مقدمه: از یک PR کوچک تا مسئولیت راهبری

این مقاله مسیر حرفه‌ای لیز رایس (Liz Rice) را از مهندسی شبکه تا راهبری جامعه و آموزش امنیت ابر بومی دنبال می‌کند. منبع نخست، گفت‌وگوی CNCF در ۸ ژوئن ۲۰۲۰ است؛ در آن زمان او رئیس کمیتهٔ نظارت فنی (Technical Oversight Committee یا TOC) و «مدیر ارشد متن‌باز» (Chief Open Source Officer) در Isovalent معرفی شد [منبع ۱]. منبع دوم، صفحهٔ رسمی Isovalent برای KubeCon + CloudNativeCon Japan در ۲۸ تا ۳۰ ژوئیهٔ ۲۰۲۶ است که او را سخنران «Isovalent at Cisco» معرفی می‌کند [منبع ۲]. این تفاوت زمانی مهم است: عنوان سال ۲۰۲۰ را نباید بدون مدرک به سال ۲۰۲۶ تعمیم داد. متن حاضر میان واقعیت منبع و تحلیل تحریریه تمایز می‌گذارد و از ساختن رزومه یا ادعای ثبت‌نشده پرهیز می‌کند.

خط زمانی زندگی حرفه‌ای؛ آنچه واقعاً ثبت شده است

رایس در گفت‌وگوی CNCF می‌گوید نخستین جرقهٔ علاقه‌اش به برنامه‌نویسی در کودکی و با رایانهٔ ZX80 شکل گرفت. آغاز کار حرفه‌ای او در نرم‌افزار پروتکل شبکه بود. سپس در شرکت‌های مصرف‌کننده‌محور Skype و Last.fm کار کرد و در مقطعی روی سرویس پیشنهاددهی فیلم و تلویزیون فعالیت داشت. آشنایی او با Docker در محیط یک شتاب‌دهنده، به راه‌اندازی شرکت Microscaling انجامید؛ شرکتی که موضوعش مقیاس‌دهی خودکار کانتینرها بود، پیش از آنکه این ایده همه‌گیر شود. بعدتر به Aqua Security پیوست و به‌طور عمیق‌تری در امنیت ابر بومی درگیر شد [منبع ۱].

نخستین مشارکت متن‌باز ثبت‌شده‌ای که با جست‌وجو پیدا کرد، PR سال ۲۰۱۲ با عنوان «Make social-friends-finder work with django-allauth» بود. او از تازه‌واردان می‌خواهد با تغییر کوچک آغاز کنند یا ایده را پیش از نوشتن هزاران خط کد توضیح دهند؛ PR بزرگ بررسی را دشوار می‌کند. از نگاه او، همکاری و پرسش از نگه‌دارندگان به‌اندازهٔ کدنویسی مهم است [منبع ۱].

از تجربهٔ پروژه تا راهبری CNCF

او برای ارائه‌های فنی خود دمو و کد منتشر می‌کرد تا دیگران آن‌ها را بیازمایند. آزمایش ایده، ساخت نمونهٔ اثبات مفهوم (Proof of Concept یا PoC) و دریافت بازخورد، برایش انگیزه‌بخش بود. این الگو حلقه‌ای میان یادگیری، انتشار، استفاده و بازخورد می‌سازد.

CNCF در سال ۲۰۲۰ نوشت که رایس در رویدادهای ۲۰۱۸ KubeCon + CloudNativeCon در کپنهاگ، شانگهای و سیاتل هم‌ریاست برنامه را بر عهده داشته است. دن کوهن او را دعوت کرد و نخستین هم‌ریاستش کلسی هایتاور بود. رایس می‌گوید برنامه باید بازتاب خواستهٔ جامعه باشد، هرچند رضایت همگان ممکن نیست؛ خاطرهٔ تعامل حضار در کپنهاگ نیز همین وجه انسانی کنفرانس را نشان می‌دهد [منبع ۱].

پس از هم‌ریاست، می‌خواست در CNCF بماند. آماده‌سازی سخنرانی‌های به‌روزرسانی پروژه برای سه KubeCon او را با سراسر چشم‌انداز پروژه‌ها آشنا کرده بود. او این دانش را همراه با تجربهٔ مهندسی نرم‌افزار، مبنای نامزدشدن در TOC دانست و با تشویق دیگران برای نقش راهبری اقدام کرد.

TOC چه مسئله‌ای را دنبال می‌کرد؟

به‌گفتهٔ رایس در سال ۲۰۲۰، رشد اکوسیستم ابر بومی حجم کار TOC را بالا برده بود؛ اعضا این مسئولیت را کنار شغل تمام‌وقت انجام می‌دادند. او از ساده‌سازی فرایندها و استفاده از مهارت افراد بیشتر، از جمله گروه‌های علاقهٔ ویژه (SIGs)، سخن می‌گوید، اما تأکید دارد ارزیابی پروژه به فهرست بله/خیر تقلیل‌پذیر نیست و به قضاوت فنی نیاز دارد.

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

پیوند با Cilium، eBPF و امنیت کانتینر

صفحهٔ رویداد رسمی Isovalent در ژاپن، رایس را در سه جایگاه محتوایی قابل مشاهده قرار می‌دهد. نخست، سخنران جلسهٔ «A Decade of Cilium Around the World» در کنار هیروکی هانادا از Cybozu است. توضیح جلسه می‌گوید Cilium ده‌ساله شده و در شبکه‌سازی امن Kubernetes جایگاه مهمی پیدا کرده است؛ همچنین از قابلیت‌هایی مانند شبکه‌سازی کارآمد، متعادل‌سازی بار لایهٔ چهارم (L4 load balancing) و سیاست شبکه یاد می‌کند. همان توضیح، نمونهٔ Cybozu را به مهاجرت سرویس‌ها از ماشین مجازی به Kubernetes روی زیرساخت فلزی و عملیات امن و مقیاس‌پذیر مرتبط می‌کند [منبع ۲].

دوم، جلسهٔ «Detecting Compromised CI with eBPF and Cilium Tetragon» است. متن رویداد، زنجیره‌های یکپارچه‌سازی و تحویل پیوسته (CI/CD) را هدف جذابی برای مهاجم توصیف می‌کند و می‌گوید Tetragon، مؤلفهٔ امنیت زمان اجرای مبتنی بر eBPF در پروژهٔ Cilium، می‌تواند در محیط‌هایی مانند GitHub Actions نیز به‌کار رود. تمرکز جلسه بر مشاهدهٔ فعالیت فرایند و شبکه، کشف اتصال‌های خروجی غیرمنتظره و شناسایی اجرای دست‌کاری‌شده در لحظه است. این منبع از «سیگنال‌های زمان اجرا» برای کشف رفتار مخرب و از سیاست‌هایی برای تشخیص و جلوگیری از خروج داده سخن می‌گوید؛ بنابراین می‌توان آن را یک نمونهٔ مستند از امتداد آموزش امنیت کانتینر به امنیت خط لوله دانست، نه دلیلی برای ادعای پوشش کامل همهٔ تهدیدها [منبع ۲].

سوم، معرفی کتاب «What is eBPF?» است. صفحه می‌گوید رایس، نویسندهٔ ویرایش دوم کتاب، در غرفهٔ Isovalent حاضر بوده تا نسخه‌ها را امضا کند. همین مورد نشان می‌دهد آموزش برای او فقط سخنرانی سازمانی نیست و به یک اثر آموزشی مکتوب نیز گره خورده است. صفحهٔ CNCF نیز نشان می‌دهد که انتشار دمو و کد سخنرانی برای آزمودن ایده‌ها بخشی از روش مشارکت او بوده است. در نتیجه، آموزش در این مسیر سه شکل دارد: توضیح مفاهیم در کتاب، انتقال تجربه در جلسهٔ فنی، و قراردادن نمونهٔ قابل‌آزمایش در اختیار جامعه.

معماری مفهومی؛ از کرنل تا سیاست امنیتی

در جلسهٔ دیگر همین رویداد با عنوان «Beyond Power and Magic»، مسئلهٔ اصلی eBPF ورود ابزارها به عملیات پایدار تولیدی معرفی می‌شود. توضیح جلسه میان ابزارهای کلاسیک مانند kprobe و tracepoint و سازوکارهای جدیدتر مانند fentry/fexit و kfunc تمایز می‌گذارد و BTF و CO-RE را به‌عنوان روش‌هایی برای سازگاری برنامه‌ها با کرنل‌های مختلف مطرح می‌کند. این‌ها جزئیات مستندشدهٔ صفحهٔ رویدادند، اما صفحه ادعا نمی‌کند که انتخاب هر سازوکار در همهٔ محیط‌ها بهترین است.

برای خوانش معماری، می‌توان یک زنجیرهٔ تحلیلی ساخت: eBPF رویدادهای نزدیک به کرنل و فرایند را مشاهده می‌کند؛ مؤلفه‌ای مانند Tetragon سیگنال را به سیاست پیوند می‌دهد؛ و نتیجه برای تشخیص یا ممانعت به‌کار می‌رود. در لایهٔ شبکه، صفحهٔ رویداد Cilium را با شبکه‌سازی، سیاست شبکه و متعادل‌سازی بار در Kubernetes مرتبط می‌کند. این مدل، جزئیات نسخه‌ای خاص نیست.

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

تحلیل تأثیر بر اکوسیستم

اثر رایس را، بدون عددسازی، می‌توان در اتصال چند نقش دید: مشارکت‌کننده‌ای که PR کوچک را جدی می‌گیرد، مهندسی که PoC و کد دمو منتشر می‌کند، مدیر برنامه‌ای که صدای جامعه را وارد کنفرانس می‌کند، و راهبری که تجربهٔ کاربران تولیدی را مهم می‌داند. صفحهٔ ۲۰۲۶ نیز او را کنار Cilium، Tetragon، eBPF و کتاب آموزشی قرار می‌دهد؛ از این منظر، جامعه‌سازی و فناوری امنیتی در روایت رسمی به هم پیوند دارند.

از این دو منبع نمی‌توان تعداد کاربران، سهم او در کد Cilium یا نتیجهٔ قطعی سخنرانی‌ها را استخراج کرد. «استاندارد دوفاکتو» نیز توصیف صفحهٔ رویداد است، نه رتبه‌بندی مستقل. دقت حرفه‌ای یعنی مرز ادعای ناشر و دادهٔ قابل‌اندازه‌گیری حفظ شود.

مزایا و محدودیت‌ها برای تیم‌های فنی

مزایا: نخست، مسیر یادگیری از مسئلهٔ ملموس شروع می‌شود: یک PR کوچک یا دمو قابل‌اجرا. دوم، Cilium و Tetragon در متن رویداد با نیازهای عملی مانند سیاست شبکه، L4، مهاجرت، مشاهدهٔ فرایند و پایش خروجی پیوند می‌خورند. سوم، eBPF امکان گفت‌وگو دربارهٔ رفتار زمان اجرا را در کنار شبکه و امنیت فراهم می‌کند. چهارم، حضور کاربر تولیدی مانند Cybozu در جلسه، الگوی مفیدی برای شنیدن تجربهٔ بهره‌برداری است.

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

کاربردهای عملی و مجاز

۱. آزمایش آموزشی: تیمی کوچک می‌تواند از یک محیط آزمایشگاهی جداگانه آغاز کند، مفهوم eBPF، تفاوت مشاهدهٔ فرایند و شبکه و نقش سیاست را آموزش دهد و تغییرات را در یک PR کوچک مستند کند.

۲. حفاظت از CI/CD: در یک خط لولهٔ متعلق به خود سازمان، رفتار عادی jobها را ثبت کنید؛ اتصال خروجی غیرمنتظره یا اجرای فرایند ناآشنا را به‌عنوان سیگنال بررسی کنید؛ سپس در محیط آزمایشی سیاست بازدارنده را فعال کنید. هدف، کشف و جلوگیری از خروج داده در محیط مجاز است، نه آزمایش روی حساب دیگران.

۳. شبکهٔ Kubernetes: برای یک سرویس آزمایشی، نیاز ارتباطی را مستند کنید، سیاست کمینه بنویسید، L4 load balancing را جداگانه آزمون کنید و نتیجه را با تجربهٔ اپراتور مقایسه کنید. مهاجرت از ماشین مجازی به Kubernetes باید مرحله‌ای و قابل بازگشت باشد.

۴. پایداری eBPF: پیش از ارتقای کرنل، ابزار را در نسخهٔ هدف آزمایش کنید؛ از سازوکارهای معرفی‌شده در صفحه، مانند BTF و CO-RE، به‌عنوان موضوع ارزیابی استفاده کنید و نتیجه را با نسخه، پلتفرم و سناریوی واقعی ثبت نمایید.

راهنمای گام‌به‌گام دفاعی

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

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

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

گام چهار، واکنش را تمرین کنید. اگر Tetragon یا ابزار eBPF سیگنال غیرعادی داد، job را متوقف یا قرنطینه کنید، اعتبارنامه‌های در معرض خطر را تعویض کنید، شواهد را حفظ کنید و منشأ تغییر را بررسی نمایید. اجرای کورکورانهٔ اسکریپت‌های واکنش می‌تواند شواهد را از بین ببرد.

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

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

چک‌لیست سردبیر و مهندس

  • [ ] عنوان و سمت فرد با تاریخ منبع همان دوره نوشته شده است.
  • [ ] بین «Isovalent در سال ۲۰۲۰» و «Isovalent at Cisco در رویداد ۲۰۲۶» خلط نشده است.
  • [ ] Cilium، Tetragon، eBPF و کتاب «What is eBPF?» فقط در حدی آمده‌اند که صفحهٔ رسمی مستند کرده است.
  • [ ] هیچ CVE، امتیاز CVSS، نسخه یا قابلیت تأییدنشده به متن اضافه نشده است.
  • [ ] هر آزمایش فقط روی زیرساخت مجاز و جداشده انجام می‌شود.
  • [ ] لاگ‌های امنیتی حداقل‌گرا، محافظت‌شده و زمان‌دار هستند.
  • [ ] برای ارتقای کرنل، آزمون سازگاری و برنامهٔ بازگشت وجود دارد.
  • [ ] هشدار eBPF بخشی از فرایند پاسخ‌گویی است، نه جایگزین تمام کنترل‌های امنیتی.

پرسش‌های متداول

آیا می‌توان گفت رایس اکنون همان مدیر ارشد متن‌باز سال ۲۰۲۰ است؟

خیر. منبع CNCF این عنوان را در انتشار ۲۰۲۰ ثبت کرده است، اما صفحهٔ رویداد ۲۰۲۶ او را «Isovalent at Cisco» معرفی می‌کند. برای حفظ دقت، باید عنوان هر منبع را با تاریخ خودش نقل کرد و دربارهٔ سمت فعلی فراتر از صفحهٔ ۲۰۲۶ نتیجه‌گیری نکرد.

نقش او در TOC دقیقاً چه بود؟

CNCF در ژوئن ۲۰۲۰ می‌نویسد او در نقش رئیس TOC قرار گرفته و دربارهٔ مدیریت رشد کار، ساده‌سازی فرایندها، استفاده از SIGها و نزدیک‌ترشدن به کاربران نهایی توضیح می‌دهد. همان صفحه همچنین مسیر قبلی او به‌عنوان هم‌ریاست KubeCon و دانش حاصل از بررسی چشم‌انداز پروژه‌ها را شرح می‌دهد.

آیا eBPF به‌تنهایی امنیت CI را حل می‌کند؟

خیر. صفحهٔ Isovalent یک کاربرد مشخص برای Tetragon را نشان می‌دهد: مشاهدهٔ سیگنال‌های فرایند و شبکه، کشف اتصال خروجی غیرمنتظره و تشخیص یا جلوگیری از رفتار مخرب در CI. این قابلیت باید کنار کنترل هویت، اسرار، سطح دسترسی، بازبینی تغییر و پاسخ به رخداد قرار گیرد.

چرا پایداری ابزار eBPF مهم است؟

چون صفحهٔ رویداد مسئلهٔ دوام در برابر ارتقای کرنل، تغییر پلتفرم و اجرای مداوم را برجسته می‌کند و سازوکارهایی مانند kprobe، tracepoint، fentry/fexit، kfunc، BTF و CO-RE را موضوع مقایسه قرار می‌دهد. نتیجهٔ عملی، آزمون پیش از تغییر و ثبت نسخه‌هاست؛ نه انتخاب خودکار یک فناوری.

بهترین نقطهٔ شروع برای مشارکت متن‌باز چیست؟

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

نتیجه‌گیری

روایت Liz Rice یک زنجیرهٔ قابل‌ردگیری از تجربه است: علاقه به رایانه، مهندسی شبکه، کار در سرویس‌های مصرف‌کننده، تجربهٔ مقیاس‌دهی کانتینر، ورود عمیق‌تر به امنیت ابر بومی، مشارکت متن‌باز، برگزاری برنامه‌های KubeCon و سپس مسئولیت TOC در روایت CNCF سال ۲۰۲۰. صفحهٔ رسمی Isovalent در سال ۲۰۲۶ این مسیر را در صحنه‌ای تازه نشان می‌دهد: سخنرانی دربارهٔ دههٔ Cilium، امنیت CI با eBPF و Tetragon، بحث پایداری ابزارهای eBPF و امضای ویرایش دوم کتاب «What is eBPF؟». ارزش تحریریهٔ این داستان در یک ادعای بزرگ دربارهٔ قهرمان فناوری نیست؛ در نشان‌دادن این است که اثرگذاری پایدار از پیوند کد کوچک، آموزش روشن، گوش‌دادن به کاربر تولیدی و تصمیم‌گیری مسئولانه ساخته می‌شود. برای تیم‌های امروز، پیام کاربردی روشن است: فناوری را در محیط مجاز و مرحله‌ای آزمایش کنید، دادهٔ امنیتی را با احترام به حریم خصوصی مدیریت کنید، و هر عنوان شغلی یا ادعای فنی را به تاریخ و منبع مشخص گره بزنید.

TRACEABLE KNOWLEDGE

منابع و مطالعهٔ بیشتر

01
CNCF: Liz Rice – How one PR leads to TOC leadership (۸ ژوئن ۲۰۲۰)https://www.cncf.io/humans-of-cloud-native/liz-rice-how-one-pr-leads-to-toc-leadership/
02
Isovalent: Meet Isovalent at KubeCon + CloudNativeCon Japan (۲۸ تا ۳۰ ژوئیه ۲۰۲۶)https://isovalent.com/events/cilium-and-ebpf-kubecon-jp-2026/
IROSG / EDITORIAL

خبرها و معرفی مشاهیر با نگارش مستقل و ذکر منبع تهیه شده‌اند. اعتبار و مجوز تصاویر در بخش منابع همین صفحه نگه‌داری می‌شود تا متن زیر عکس‌ها شلوغ نشود. داده‌های مرجع CVE با اعتباردهی به منابع اصلی ارائه می‌شوند.

سیاست تألیف و حقوق تصاویر ↗
جی. سی. آر. لیکلایدر؛ شبکه‌سازی تعاملی و همزیستی انسان و رایانهآشنایی با مشاهیر
توسعه و DevSecOps

جی. سی. آر. لیکلایدر؛ شبکه‌سازی تعاملی و همزیستی انسان و رایانه

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

14 دقیقه مطالعهبخوانید