ايميل:

كلمه عبور:


مرا از مطلب‌های جدید باخبر کن!
ايميل من:


فهرست مطالب


ارائه توسط: Brian Brazil
مترجم: محمد علی بزرگ زاده 1397/10/20
در این اپیزود که در اکتبر ۲۰۱۶ منتشر شده است جف میرسون با برایان برزیل در مورد ابزار مانیتورینگ Prometheus صحبت می‌کند. برایان، مؤسس Robust Perception است. این شرکت، کمک می‌کند که کاربران ابزار متن‌باز Prometheus افزایش یافته و آن‌ها را پیشتیبانی می‌کند. برایان به شدت، به پروژه Prometheus تعهد دارد. او قبل از شرکت Robust Perception در گوگل کار می‌کرد.
برایان، به SE Radio خوش آمدی.
سلام جف، خوشحالم که اینجا هستم.
بگذار با صحبت در مورد مانیتورینگ آغاز کنیم. مانیتورینگ چیست؟
طی سال گذشته با افراد زیادی صحبت کرده‌ام. افراد مختلف، درباره اینکه مانیتورینگ چیست، برداشت‌های خیلی متفاوتی دارند. برای مثال، وقتی می‌گفتم من کار مانیتورینگ را انجام می‌دهم، برخی افراد بودند که فکر می‌کردند که من به ترافیک شبکه‌شان نگاه می‌کنم تا ببینم آیا در محل کار، سراغ فیسبوک می‌روند یا خیر. روشن است که ما چنین کاری نمی‌کنیم.
من مانیتورینگ را در چهار چیز می‌بینم. یکی این است که وقتی مشکلی ایجاد شده یا احتمال مشکلی (یک مشکل کسب و کار) وجود دارد، به شما هشدار دهد. دوم، این است که اطلاعاتی که برای دیباگ آن مشکل نیاز دارید را به شما بدهد. مورد سوم، نمایش روندهای بلندمدت برای اخذ تصمیمات کسب و کار است. مثلاً اگر بدانید که نرخ موفقیت از کَش (Cache Hit Rate) فرضاً ۹۰٪ باشد و اگر تغییر شما بخواهد آن را ۹۵٪ بکند، به این معناست که می‌توانید از دست سخت‌افزارش خلاص شوید و آن را [برای کار دیگری] اضافه کنید. مورد چهارم، لوله‌‌کشی‌های کلی است. برای مثال، اگر هارد دیسک خراب شود، دست آخر، باید فردی را بفرستید که آن را تعمیر کند چون هنوز روبات‌ها برای انجام این کار به قدر کافی خوب نیستند. این‌ها، ۴ چیزی هستند که من در ارتباط با مانیتورینگ در فضای کام‍پیوترها، می‌بینم.
عالی. یک مثال از چیزهایی بزنید که وقتی در گوگل کار می‌کردید، آن را مانیتور می‌کردید.
من قبلاً در بخش Ads در گوگل کار می‌کردم. بنابراین ما چیزهایی از قبیل تعداد پرس‌وجوهای ورودی در ثانیه را مانیتور می‌کردیم. مدت زمان تأخیر (Latency) و همینطور جزییات سیستم‌ها را هم مانیتور می‌کردیم. بنابراین ما خربارها داده آماری داشتیم.
درست است. می‌خواهم بعداً از آن، جهت مثال استفاده کنم.
ما امروز در مرود Prometheus صحبت می‌کنیم. و شما ادعا کرده‌اید که Prometheus نسل بعدی سیستم‌های مانیتورینگ است. آیا می‌توانید در این مورد صحبت کنید که مانیتورینگ با Prometheus با ابزارهای نسل‌های قبلی چه تفاوتی دارد؟
اگر به نسل‌های قبل نگاه کنید فرضاً چیزی مانند Nagios را یا چیزهای دیگر منتج از آن را می‌بینیم که چند مورد هستند. Nagios براساس قاعده «بررسی کردن هر ماشین» کار می‌کند. درواقع، یک شِل‌اسکریپت را اجرا می‌کنم که خروجی درست یا غلط برمی‌گرداند و براساس آن یک هشدار به کاربر انسانی می‌فرستم. اگر ۵ ماشین داشته باشید که مراقب‌شان بوده و آن‌ها را نگهداری و تغذیه می‌کنید، این می‌تواند خوب باشد اما در نسل کنونی که افراد در مورد [معماری] بدون سرور (Serverless)، ابر و [کدهای] بومی ابر (Cloud Native) صحبت می‌کنند، ممکن است هزارها ماشین کوچک داشته باشید که دائم آشکار و پنهان می‌شوند. بنابراین، آن هشدارهای در سطح ماشین‌های منفرد آنقدرها مفید نیست.
همچنین ممکن است یک ماشین، کمی کند باشد اما این لزوماً به آن معنی نیست که آن سرویس در کل مشکلی داشته باشد. چون ممکن است همچنان SLA را برآورده کنید. به عنوان یک مثال فنی، فرض کنید که نوعی وب‌سرویس را اجرا می‌کنید. و در مورد میزان تأخیر (Latency) یک SLA دارید که می‌گوید تأخیر باید زیر یک ثانیه باشد. در این حالت خیلی دشوار است که فقط از Nagios استفاده کنید و برای تأخیر بیش از یک ثانیه هشدار داشته باشید. چون فقط می‌توانید به هرکدام از ماشین‌ها نگاه کنید و باید این داده را به نوعی فراهم کنید و نمی‌توانید دید کلی سطح سرویس را ببینید. در نهایت افراد به این می‌رسند که وقتی CPU بالا رفت، هشدار دهند. این می‌تواند حاکی از چنین مشکلی باشد مثلاً ممکن است به خاطر یک بن‌بست (Deadlock) باشد اما موارد زیادی از مثبت‌های اشتباهی (False Positive) هم می‌تواند باشد فرضاً اگر چرخش [فایل‌های] لاگ کمی بیشتر زمان برده باشد.
ادامه مطلب ...

ارائه توسط: Patrick Kua
مترجم: سید مرتضی هاشمی 1396/11/08
در این قسمت که در آگوست ۲۰۱۶ منتشر شده است یوهان سوِن با پاتریک کوآ درباره‌ی نقش رهبر فنی (Technical Lead) و چگونگی تبدیل شدنِ یک فرد، به رهبر فنی صحبت می‌کند. تعریف رهبر فنی، مسئولیت‌های این نقش و چالش‌های تبدیل شدن به یک رهبر فنی، از جمله موضوعاتی هستند که در این گفتگو مطرح می‌شود.
به یک برنامه‌ی دیگر از رادیوی مهندسی نرم‌افزار خوش آمدید. امروز با پاتریک کوا هستم. به رادیوی مهندسی نرم‌افزار خوش آمد پاتریک! خوشحالیم که با ما هستی.
ممنونم که مرا دعوت کردید، خوشحالم که با شما صحبت می‌کنم.
پاتریک کوا یک مشاور ارشد و یک رهبر فنی در ThoughtWorks است. معمولاً در لندن زندگی می‌کند، هرچند در حال حاضر در برلین کار می‌کند. او در زمینه‌ی توسعه‌ی نرم‌افزار بیش از یک دهه تجربه دارد و تمرکزش بر افراد، کسب و کار و فناوری است. ممکن است او را به واسطه‌ی کتاب The Retrospective Handbook و یا کتاب جدیدترش، Talking with Tech Leads بشناسید. پاتریک همچنین در زمینه‌ی آموزش رهبری فنی، هم به صورت داخلی در ThoughtWorks و هم در خارج از آن فعالیت داشته است. من در یکی از این آموزش‌های او بوده‌ام. موضوع این برنامه چگونگی تبدیل شدن به یک رهبر فنی است که کاملاً منطبق [با تجربیات او] است.
پاتریک آیا چیز دیگری هست که بخواهی در مورد خودت بگویی؟
نه، خیلی خوب خلاصه‌اش کردی.
برای این‌که جای ابهامی باقی نماند، هم من و هم پاتریک در ThoughtWorks کار می‌کنیم. برای همین من در یکی از آموزش‌های او شرکت کردم. اولین سؤالی که هنگام صحبت کردن در مورد رهبری فنی به ذهن می‌رسد این است که نقش رهبر فنی چیست؟ وقتی من یک رهبر فنی می‌شوم چه مسئولیت‌هایی دارم؟
این سوال خیلی خوبی است. اول از همه باید بگویم که فقط یک تعریف خوب در اینباره وجود ندارد، چون هر سازمانی این نقش را به شکلی متفاوت تلقی می‌کند. من با تعداد زیادی از مشتریان در سازمان‌های متفاوت کار کرده‌ام؛ فکر می‌کنم بتوانم آن‌چه که به نظرم ویژگی‌های مشترک مسئولیت‌های یک رهبر فنی است را بگویم.
در برخی سازمان‌ها به رهبر فنی، توسعه‌دهنده‌ی پیشرو اطلاق می‌شود؛ در سایر سازمان‌ها به آن معمار می‌گویند. به نظر من، ترکیب این دو تفکر این است که رهبر فنی، نقشِ یک معمار نیست که خارج از تیم است. در واقع یک توسعه‌دهنده است. کسی که دارای مهارت‌های توسعه است و مسئولیت رهبری تیم را بر عهده دارد. این نقش با نقش توسعه دهنده‌ی ارشد کاملاً متفاوت است، که هدایت یک حوزه در بخشی از سیستم را بر عهده دارد. رهبر فنی سعی می‌کند بر اثرگذاری کلی تیم تمرکز کند. من انتظار دارم که یک رهبر فنی تا حدی کد بنویسد و همچنین در سطوح فنی کار کند.
آنچه که به نظر من رهبر فنی نیست، چیزی است که افراد اغلب به آن مدیر فنی می‌گویند. کسی که بیشتر مسئولِ پیشرفت افراد و گزارش‌هاست اما لزوماً درگیر معماری نیست. حتی اگر پیش‌زمینه‌ی فنی داشته باشد لزوماً بر سیستم متمرکز نیست. انتظار دارم که مدیران فنی با رهبر فنی در تعامل باشند.
در بسیاری شرکت‌های دیگر استاد اسکرام (Scrum Master) نقش خیلی محبوبی است و به نظر من، این نقش خیلی متفاوت [از رهبر فنی] است، هر چند یک رهبر فنی می‌تواند استاد اسکرام هم باشد. استاد اسکرام بودن، لزوماً به صورت خودکار از شما یک رهبر فنی نمی‌سازد.
این جنبه، شاخص است که رهبر فنی همچنان یک توسعه‌دهنده است که بر اثرگذاری تیم تمرکز دارد.
درست است.
آیا در مقام مقایسه موافقید که مدیر فنی منحصراً بر تیم تمرکز دارد، معمار منحصراً بر فناوری تمرکز دارد، و توسعه‌دهنده‌ی ارشد کسی است که مالک بخش خاصی از سیستم است؟
بله، درست است. تأکید می‌کنم که این‌ها مربوط به نقش‌ها هستند، و این به آن معنی نیست که یک سازمان برای هر یک از نقش‌ها فرد مجزایی خواهد داشت. گاهی یک فرد چند تا از این نقش‌ها را بازی می‌کند. ممکن است رهبر فنی نقش مدیر فنی را هم داشته باشد که مراقب افرادِ خط تولید است، و ممکن است در عین حال ارشدترین عضو تیم هم باشد. اما در شرایط دیگر، مثلاً از نظر اندازه‌ی تیم یا نحوه‌ی ساختاردهی یک سازمان، ممکن است نقش‌های جداگانه‌ای هم باشند.
من نوعی از تقسیم [وظایف] را [در نقش رهبر فنی] می‌بینم؛ یک جنبه‌ی فنی که مربوط به معماری و مسیر سیستم است، و جنبه‌ی مدیریت افراد و پروژه که ممکن است بیشتر مربوط به مدیر فنی باشد. این یک الگوی متداول است که می‌بینم. اما تأکید می‌کنم که این یک نقش است و به این معنی است که مجموعه‌ای از مسئولیت‌ها را شامل می‌شود.
پیش از آن‌که در این موضوع عمیق‌تر شویم آیا ممکن است توضیح دهید که دقیقاً چرا به رهبر فنی نیاز داریم؟
بله، این سؤال خیلی خوبی است. وقتی در کنفرانس‌ها در مورد این‌که رهبر فنی چیست صحبت می‌کنم، یکی از سؤالاتی که عموماً پرسیده می‌شود این است که «چرا به آن نیاز داریم؟» قطعاً می‌توانم شرایطی را تصور کنم که در یک تیم کوچک کار می‌کنید و همه به خوبی با هم کنار می‌آیند و هر کس می‌داند که باید چه کاری انجام دهد؛ در چنین شرایطی شاید به یک رهبر فنی احتیاجی نباشد، چون همه کارشان را می‌دانند و به خوبی هماهنگ شده‌اند. این یک وضعیت ایده‌آل است و بسیاری تیم‌ها هستند که در وضعیت آشفته‌تری هستند و ترکیبی از مهارت‌های متفاوت دارند. عموماً ممکن است درباره‌ی نحوه‌ی پیاده‌سازی یا مسیر سیستم و معماری ابهاماتی وجود داشته باشد. خیلی خوب است که توسعه‌دهندگانی که توانایی گرفتن چنین تصمیماتی دارند، این تصمیمات را در کارهای خودشان بگیرند. اما زمانی که افراد در مقابل یکدیگر قرار می‌گیرند با یک آشفتگی مواجه می‌شوید. به نظر من یکی از وظایف یک رهبر فنی این است که کاری کند توسعه‌دهندگان به شکلی اثربخش در یک جهت فعالیت کنند.
ادامه مطلب ...

ارائه توسط: John Purrier
مترجم: محمد علی بزرگ زاده 1396/10/21
در این اپیزود که در ژوئن ۲۰۱۶ منتشر شده است جف میرسون با جان پریر در مورد OpenStack صحبت می‌کند. OpenStack یک سیستم‌عامل ابری متن‌باز است. جان پریر بنیانگذار OpenStack و مدیر ارشد فنی Automic Software است. به عنوان مدیرارشد فنی، او مسئولیت راهبری استراتژی خودکارسازی (Automation) را بر عهده دارد. او که بیش از ۲۰ سال تجربه رهبری در صنعت IT را دارد، اخیراً مدیرارشد فنی آزمایشگاه ابداعات CenturyLink شده است و بر روی فناوری‌های جدید و درحال ظهور ابری، شامل قابلیت همکاری بین ابری و DevOps تمرکز دارد. جان قبلاً رهبر راهبردی و فناوری AppFog بوده است و رهبری توسعه و تحویل اولین نسخه Microsoft Exchange Server را هم بعهده داشته است. او همچنین، رهبری R&D را در RackSpace انجام می‌دهد.
جان، به SE Radio خوش آمدی.
از اینکه دعوتم کردید متشکرم.
OpenStack چیست؟
همانطور که شما گفتید یک پروژه متن‌باز است. یک سیستم‌عامل ابری است. اساساً ایده پشت OpenStack ساختن یک زیرساخت متن‌باز به منزله یک پلتفرم به عنوان خدمت (Platform as a Service) است. بنیانگذاران اولیه، RackSpace و NASA بودند. دو پروژه اول، یکی پروژه محاسبات و دیگری یک پروژه ذخیره‌سازی اشیاء بود. از آن زمان طی ۶ سال اخیر، تعداد پروژه‌ها و محدوده آن‌ها خیلی فراتر از آن دید اولیه شده است.
برای آن دسته از مخاطبان که ممکن است این اصطلاح را ندانند بگویید زیرساخت به عنوان خدمت (Infrastructure as a Service) چیست؟
می‌توان اینطور دید که به جای اینکه بروید و کامپیوترهای خود را بخرید، یک ساختمان بیابید، آن را اجاره کنید، برق و سیستم تهویه‌اش را برپا کنید و یک مرکز داده برپا کنید، در عوض، آن را از کس دیگری اجاره می‌کنید. در حالی که می‌توانید پروژه‌های زیرساخت به عنوان خدمت خصوصی هم داشته باشید، وقتی از زیرساخت به عنوان خدمت صحبت می‌کنیم، اغلب افراد زیرساخت‌های ابری عمومی مانند Amazon و Azure و Google Cloud را در نظر می‌آورند. بنابراین نگاه ساده‌اش این است که سرورها را از کس دیگری اجاره می‌کنم.
ما این ابرهای عمومی مانند Amazon و Azure و Google Cloud را داریم. چرا به یک سیستم‌عامل ابری متن‌باز نیاز داریم؟
سئوال خوبی است. فکر می‌کنم سئوال می‌تواند به این شکل باشد که چرا به ازای هرکدام از پیاده‌سازی‌های اختصاصی به یک نسخه متن‌باز هم نیاز داریم. من اینطور استدلال می‌کنم که اول از همه، برای صنعت و اکوسیستم خوب است. اما بطور خاص زیرساخت‌های ابری، خیلی مبتنی بر همکاری هستند. شرکت‌ها و سازمان‌های زیاد مختلفی با هم جمع می‌شوند. این توانایی که بتوانیم یک پروژه بزرگ مانند این را با همکاری هم بسازیم خیلی قدرت‌بخش است. شرکت‌های خیلی کمی در دنیا هستند که بتوانند پروژه‌ای که به بزرگی OpenStack امروز باشد را راه‌اندازی و نگهداری کنند. آخرین باری که دیدم، بیش از ۳۰۰۰۰ عضو بنیاد OpenStack بودند که در بهبود نرم‌افزار مشارکت می‌کنند که چیز خیلی خوبی است.
بنابراین، این، همان سیستم‌عامل متن‌بازِ زیرساخت به عنوان سرویس است. آیا می‌توانید مثالی از شرکت‌هایی بزنید که امروزه از OpenStack استفاده می‌کنند تا یک نمونه کاربرد اولیه داشته باشیم که شاید در ادامه بحث به آن ارجاع داشته باشیم.
صدها شرکت هستند که امروزه به شکل‌های مختلف از OpenStack استفاده می‌کنند. برخی از آن‌ها حالت تصویر تبلیغاتی‌مان را دارند. از تجاری‌های‌شان، Wal-Mart است. Wal-Mart برای توسعه سیستم تجارت الکترونیک خود، در مراکز داده‌شان، از OpenStack استفاده می‌کنند. مورد دیگر آزمایشگاه تحقیقاتی CERN است که در سوییس یک برخورددهنده بزرگ مقیاس می‌سازد. هرکسی که در نشست‌های اخیر طراحی OpenStack بوده‌، [مشاهده کرده است که] هر دو این سازمان‌ها پیش‌قدم شده‌اند و نحوه استقرار بزرگ‌مقیاس خود را ارائه کرده‌اند.
آیا این سازمان‌ها، سرورهای خود را دارند و OpenStack را بر روی آن اجرا می‌کنند یا اینکه یک میزبان ابری را اجاره کرده‌اند که OpenStack را بر روی آن قرار داده‌اند؟
سئوال خوبی است. بسته به سازمان، ممکن است هرکدام از این‌ها یا هردو را انجام دهند. نحوه مرسوم نصب OpenStack این است که در یک ابر درمحل (On-premises) یعنی خصوصی باشد. بنابراین [احتمالاً شرایط در هنگام نصب به این شکل است که] مرکز داده خودم را دارم و احتمالاً مجازی‌سازی کرده‌ام و طی ۱۰ سال اخیر، با استفاده از VMware یا دیگر فناوری‌های مجازی‌سازی، این کار را انجام داده‌ام و حال واقعاً می‌خواهم که خدمات بیشتر، خودکارسازی‌های بیشتر و پاسخگویی‌های بیشتری برای مشتری‌های داخلی خود داشته باشم.
ادامه مطلب ...