معرفی و دانلود کتاب DevOps برای همه

معرفی کتاب DevOps برای همه

امیلی فریمن در کتاب DevOps برای همه به معرفی دواپس و چگونگی استفاده‌ از آن برای همکاری بهینه‌ی تیم توسعه نرم‌افزار و عملیات در کنار یکدیگر پرداخته است. این کتاب از مجموعه‌ی دامیز می‌تواند اطلاعات مفیدی درباره‌ی دواپس به افراد کاملا مبتدی تا پیشرفته ارائه دهد.

درباره‌ی کتاب DevOps برای همه

امروزه با وجود پیشرفت سریع سخت‌افزارها و نرم‌افزارهای مختلف، دیگر لزومی ندارد که نگران کامپیوترهایمان باشیم. بلکه چیزی که در این میان اهمیت بیشتری پیدا می‌کند، انسان‌ها هستند. دواپس (DevOps) که از اصول مدیریت چابک (Agile project management) برگرفته شده است، به سیاست‌هایی اشاره دارد که بازدهی عملیاتی شرکت‌های فناوری اطلاعات را بالاتر می‌برد. امیلی فریمن (Emily Freeman) در کتاب DevOps برای همه (DevOps For Dummies) دواپس را به‌عنوان یک فلسفه در مهندسی به مخاطبان خودش می‌شناساند. مهم نیست که این واژه را برای اولین بار شنیده یا مهندسی باشید که سال‌ها با این فلسفه سر و کار داشته، در کتاب DevOps برای همه با ابزارها و روش‌های متداول برای پیاده‌سازی دواپس آشنا می‌شوید و همچنین می‌بینید که دواپس چگونه با فرهنگ سازمانی و پیوند میان تیم‌های توسعه نرم‌افزار و عملیات می‌تواند کیفیت خروجی را به‌شکلی قابل‌توجه بهبود بخشد.

کتاب DevOps برای همه نوشته‌ی امیلی فریمن را می‌توانید با ترجمه‌ی رامین مولانا پور و عفت عالی مراد خرم آباد در انتشارات آتی‌نگر بخوانید.

کتاب DevOps برای همه برای شما مناسب است اگر

• توسعه‌دهنده‌ی نرم‌افزار یا مدیر پروژه‌های نرم‌افزاری هستید.
• به مباحثی درباره‌ی رایانش ابری و اتوماسیون علاقه‌مندید.
• مشتاقید بدانید دواپس چطور باعث افزایش سرعت و کیفیت همکاری‌ها در تیم‌های نرم‌افزاری می‌شود.

در بخشی از کتاب DevOps برای همه می‌خوانیم

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

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

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

فهرست مطالب کتاب

پیشگفتار
DevOps چیست؟
مقدمه
درباره این کتاب
مفروضات احمقانه
نمادهای مورد استفاده در این کتاب
فراتر از این کتاب
از اینجا کجا برویم
بخش اول: تشریح DevOps
فصل 1: معرفی DevOps
DevOps چیست؟
DevOps از Agile تکامل یافت
DevOps روی افراد تمرکز دارد
فرهنگ شرکت پایه و اساس DevOps است
شما با مشاهده فرایند خود و جمع‌آوری داده‌ها یاد می‌گیرید
متقاعدکردن کلید پذیرش DevOps است
تغییرات تدریجی کوچک بی‌ارزش است
بهره‌مندی از DevOps
خون‌سرد باشید
حل مسئله منفعت‌های متناقض
فصل 2: طراحی سازمان شما
ارزیابی سلامت فرهنگ شما
یکپارچه‌سازی DevOps
بنیادنهادن به ارزش‌های DevOps
کار تیمی را تشویق کنید
سیلوها را کم کنید
تفکر سیستمی را تمرین کنید
شکست اجتناب‌پذیر است
برقراری ارتباط، برقراری ارتباط، برقراری ارتباط
بازخورد را بپذیرید
فرایندهای خودکار (در صورت لزوم)
مدل‌سازی فرهنگ شرکت
پرهیز از بدترین فرهنگ فناوری
چشم‌انداز خود را ماهرانه بسازید
ایجاد انگیزه در ارزش‌ها
ارزیابی‌ها
پاداش
فصل 3: شناسایی اتلاف
بررسی دقیق هفت نوع اتلاف
فرایند غیرضروری
انتظار
حرکت
هزینه‌های نقص
تولید مازاد
حمل و نقل
موجودی
درک اتلاف در DevOps
یافتن اتلاف‌ها
کشف گلوگاه‌ها
تمرکز بر تأثیر
فصل 4: مجاب کردن همکاران به امتحان‌کردن DevOps
ترس از تغییر
متقاعدکردن اطرافیان برای انتقال به DevOps
جلب حمایت هیئت‌مدیره
ایجاد خاک‌ریز در گروه مهندسی
مدیریت مدیران میانی
متقاعدکردن افراد یک‌دنده
درک منحنی پذیرش
تلاش برای تغییر
عکس‌العمل منفی
پیمایش در شکاف
پرسیدن «چرا؟»
فصل 5: ابزار سنجش سازمان شما
اندازه‌گیری پیشرفت شما
کمّی‌سازی DevOps
جمع‌آوری داده‌ها
توسعه مطالعات موردی داخلی
بخش دوم: برپایی خط توسعه
فصل 6: پذیرش چرخه حیات توسعه جدید
دعوت از همه به میز
فرایندهای تغییر: از یک خط به یک مدار
انتقال به چپ: فکرکردن به زیرساخت
انتقال استقرار هم به سمت چپ
تقلید تولید از طریق پیش تولید
فصل 7: برنامه‌ریزی بلندمدت
حرکت ورای مدل چابک
پیش‌بینی چالش‌ها
شناسایی چالش‌ها و محدودیت‌های پروژه
برنامه زمانی
بودجه
جمع‌آوری نیازمندی‌ها
طراحی MVP
پیداکردن مشکل برای MVP شما و حل‌کردن آن
شناسایی مشتریان خود
بررسی دقیق رقابت
اولویت‌بندی ویژگی‌ها
طراحی تجربه کاربری
آزمون فرضیه خود
به بتا یا خیر؟
تعیین مشتری با طراحی شخصیت
شخصیت چیست؟
طراحی شخصیت
فصل 8: طراحی ویژگی‌ها از منظر DevOps
ساخت طراحی شما
طراحی بر اساس DevOps
طراحی نرم‌افزار بر اساس تغییر
بهبود مستمر نرم‌افزار
مستندسازی نرم‌افزار شما
معماری کد برای شش قابلیت DevOps
قابلیت نگه‌داری
مقیاس‌پذیری
امنیت
قابلیت استفاده
قابلیت اطمینان
انعطاف‌پذیری
مستندسازی تصمیمات طراحی
اجتناب از دام‌های معماری
فصل 9: توسعه کد
ارتباط بر اساس کدها
مهندسی بر اساس خطا
نوشتن کد قابل‌نگه‌داری
آزمون کد
اشکال‌زدایی کد
رویدادنگاری کد
نوشتن کد تغییرناپذیر
ایجاد کد خوانا
الگوهای برنامه‌نویسی
برنامه‌نویسی شیء‌گرا
برنامه‌نویسی تابعی
انتخاب یک زبان
اجتناب از ضدالگوها
توسعه DevOpsing
کدنویسی تمیز
شناخت کسب‌وکار
گوش‌دادن به دیگران
تمرکز روی موارد درست
کنارآمدن با نارضایتی
برپایی شیوه‌های خوب
سازماندهی کد منبع شما
نوشتن آزمون‌ها
مستندسازی ویژگی‌ها
داشتن همکارانی برای بازبینی کدهای شما
فصل 10: آزمون‌های خودکار قبل از عرضه
آزمون اختیاری نیست
اتوماسیون آزمون شما
آزمون در محیط‌های مختلف
محیط محلی
محیط توسعه
محیط آزمون
محیط پیش‌تولید
محیط تولید
فراتر از آزمون واحد
آزمون‌های واحد: زنده هستند!
آزمون‌های یکپارچه‌سازی: آیا همه قطعات با هم کار می‌کنند؟
آزمون‌های رگرسیون: پس از تغییرات، آیا کدها یکسان عمل می‌کنند؟
آزمون‌های بصری: آیا همه چیز یکسان به‌نظر می‌رسد؟
آزمون عملکرد
آزمون مستمر
فصل 11: استقرار یک محصول
عرضه کد
یکپارچه‌سازی و تحویل‌دادن به‌طور مستمر
بهره‌مندی از CI/CD
پیاده‌سازی CI/CD
مدیریت استقرارها
اتوماسیون به روش صحیح
نگارش‌سازی
کاهش شکست
عقب‌گرد
اصلاح پیشرو
مردمی‌کردن استقرارها
انتخاب یک شیوه استقرار
سبزآبی: نه فقط برای دریاچه‌ها
قناری شرودینگر: استقرار نمرده است (یا این‌طور نیست؟)
انداختن تاس
تغییر وضعیت با پرچم‌های ویژگی
پایش سیستم‌های شما
شناخت دورسنجی
ثبت رفتار
SLAها، SLIها و SLOها
بخش سوم: اتصال مدار
فصل 12: پیاده‌سازی تکرار سریع
اولویت‌بندی موارد مهم
مهم و فوری
مهم است، اما فوری نیست
فوری است، اما مهم نیست
نه مهم است و نه فوری
افزایش سرعت
بهبود عملکرد
از بین بردن کمال
طراحی تیم‌های کوچک
رهگیری کار شما
کاهش اختلاف‌نظر
انسانی کردن هشداردهی
فصل 13: ایجاد حلقه‌های بازخورد پیرامون مشتری
ایجاد یک فرایند بازخورد مشتری
ایجاد حلقه بازخورد
دریافت
تحلیل
انتقال
تغییر
جمع‌آوری بازخورد
نظرسنجی‌هایی توأم با رضایت
مطالعات موردی
پیش‌مرگی
درخواست بازخورد مستمر
امتیاز خالص ترویج‌کنندگان (NPS)
یافتن ریتم
فصل 14: DevOps یک تیم نیست (به‌جز زمانی که باید باشد)
تشکیل تیم DevOps
هم‌راستایی تیم‌های وظیفه‌ای
تخصیص یک تیم DevOps
ایجاد تیم‌های محصول فراوظیفه‌ای
مصاحبه سریع (اما نه‌خیلی سریع)
تصمیم‌گیری در مورد عنوان شغلی
استخدام هرگز پایان نمی‌یابد.
یافتن افراد مناسب
تبادل داوطلبان عالی
ارزیابی توانایی فنی
تجدیدنظر در مورد تخته‌سفید
ارائه آزمون‌های خانگی
بازبینی کدها
اخراج سریع
آدم نادان
آدم مظلوم‌نما
فردی کمتر از حد انتظار
فصل 15: توانمندسازی مهندسان
مقیاس‌گذاری تیم‌های مهندسی با DevOps
سه مرحله از یک شرکت
انگیزه دادن به مهندسان
پژوهش در مورد انگیزش
DevOpsای کردن انگیزه
اجتناب از اتکا به پاداش‌های فرعی
استقلال
تسلط
منظور
ایجاد سرگرمی کاری
اجازه‌دادن به افراد برای انتخاب تیم‌های خود
اندازه‌گیری انگیزه
بخش چهارم: تمرین کایزن، هنر بهبود مستمر
فصل 16: پذیرش خرابی با موفقیت
خرابی سریع در فناوری
خرابی به‌طور ایمن
حاوی خرابی
پذیرش خطای انسانی (و بی‌تقصیر جلوه‌دادن آن)
خرابی مطلوب
قابلیت نگه‌داری ذهنیت رشد
ایجاد استقلال برای خرابی
تشویق به آزمون فصل 17: آماده‌سازی برای حوادث
مقابله با «خطای انسانی» با اتوماسیون
تمرکز بر سیستم‌ها: اتوماسیون واقع‌بینانه
استفاده از ابزارهای اتوماسیون برای جلوگیری از مسائل یکپارچه‌سازی کد
مدیریت استقرارها و زیرساخت محدودکننده مهندسی بیش از حد
انسانی کردن شیفت کاری در حال آماده‌باش
زمانی که وظایف آماده‌باش غیرانسانی می‌شوند.
انتظارات در حال آماده‌باش انسانی
مدیریت حوادث
ایجاد ثبات برای یک آرمان
پذیرش فرایندهای استانداردشده
سازماندهی یک بودجه واقعی
آسان‌کردن پاسخ‌گویی به حوادث
پاسخ به یک اختلال برنامه‌ریزی نشده
اندازه‌گیری تجربی پیشرفت
متوسط زمان تعمیر (MTTR)
متوسط زمان بین خرابی‌ها (MTBF)
هزینه هر حادثه (CPI)
فصل 18: انجام بازبینی پس از حادثه
فراتر رفتن از تحلیل علت ریشه‌ای
گذر از یک حادثه
موفقیت در بازبینی‌های پس از حادثه
فوراً آن را زمان‌بندی کنید.
شامل همه
آن را بی‌تقصیر جلوه می‌دهد.
بازبینی زمان‌بندی
پرسش سؤالات دشوار
تأیید سوگیری گذشته‌نگر
یادداشت‌برداری
تدوین یک برنامه بخش پنجم: ابزارسازی شیوه DevOps
فصل 19: پذیرش ابزارهای جدید
یکپارچه‌سازی با نرم‌افزار متن باز
بازکردن نوآوری در جامعه
صدور مجوز متن باز
تصمیم‌گیری درباره متن باز
انتقال به زبان‌های جدید
کامپایل و تفسیر زبان‌ها
موازی‌سازی و چندریسه‌ای
برنامه‌نویسی عملکرد وظیفه‌ای
مدیریت حافظه
انتخاب زبان عاقلانه
فصل 20: مدیریت سیستم‌های توزیع‌شده
کار با مونولیت‌ها و میکروسرویس‌ها
انتخاب معماری همگن در ابتدا
در حال تکامل به میکروسرویس‌ها
طراحی APIهای عالی
آنچه در یک API وجود دارد.
تمرکز بر طراحی ثابت
کانتینرها: خیلی بیشتر از ماشین‌های مجازی
شناخت کانتینرها و Imageها
استقرار میکروسرویس‌ها در کانتینرها
مقایسه هماهنگ‌کننده‌ها: محل ذخیره اطلاعات را هماهنگ کنید.
پیکربندی کانتینرها
پایش کانتینرها: پابرجا نگه‌داشتن آن‌ها تا زمانی که آن‌ها را لغو کنید.
تأمین امنیت کانتینرها: این جعبه‌ها به قفل نیاز دارند.
فصل 21: انتقال به ابر
اتوماسیون DevOps در ابر
انتقال فرهنگ DevOps خود به ابر
یادگیری از طریق پذیرش
بهره‌مندی از خدمات ابری
کومولوس، سیروس و استیل: انواع ابرها
ابر عمومی
ابر خصوصی
ابر ترکیبی
ابر به‌منزله خدمت
زیرساخت به‌منزله خدمت
پلت‌فرم به‌منزله خدمت
نرم‌افزار به‌منزله خدمت
انتخاب بهترین ارائه‌دهنده خدمت ابری
Amazon Web Services (AWS)
Microsoft Azure
Google Cloud Platform (GCP)
یافتن ابزارها و خدمات در ابر
بخش ششم: بخش ده‌ها
فصل 22: ده دلیل برتری (امتیاز) که DevOps اهمیت دارد.
پذیرش تغییر مقدار ثابت
پذیرفتن ابر
استخدام بهترین‌ها
ماندن در رقابت
حل مسائل انسانی
کارکنان چالش‌برانگیز
پرکردن شکاف‌ها
خرابی مطلوب
در حال بهبود مستمر
با زحمت کارکردن اتوماسیون
تسریع در تحویل
فصل 23: ده اشکال غیرمنتظره برتر DevOps
اولویت‌زدایی از فرهنگ
پشت سر گذاشتن دیگران
فراموشی هم‌راستا کردن مشوق‌ها
ساکت ماندن
فراموش‌ کردن اندازه‌گیری
مدیریت خرد
تغییر خیلی زیاد، خیلی سریع
انتخاب ضعیف ابزارها
ترس از خرابی
سخت‌گیری بیش از حد