قدم به دنیای دواپس
دواپسDev-Ops چیست؟
دواپس ترکیبی از دو کلمۀ Developmentتوسعه و Operationsعملیات هست و به‌عنوان یک فرهنگ، فلسفه و مجموعه‌ای از روش‌ها و ابزارها در دنیای فناوری اطلاعات شناخته میشه. هدف اصلی دواپس، بهبود همکاری بین تیم‌های توسعۀ نرم‌افزار و تیم‌های عملیات فناوری اطلاعاته، به‌طوری که بتونن نرم‌افزارها رو با سرعت بیشتر، کیفیت بهتر و با قابلیت اطمینان بالاتر به دست کاربران برسونن.
دواپس یه فرهنگه که بر همکاری، ارتباطات و یکپارچه‌سازی بین تیم‌های مختلف تأکید داره. در گذشته، تیم‌های توسعه و عملیات به صورت جداگانه کار می‌کردن. تیم توسعه مسئول نوشتن کد و ایجاد نرم‌افزار بود، در حالی که تیم عملیات مسئول نگهداری و اجرای نرم‌افزار در محیط‌های عملیاتی بود. این جدایی گاهی اوقات منجر به مشکلاتی مثل تأخیر در تحویل، تطابق نداشتن محیط‌های توسعه و عملیات و حتی اختلافات بین تیم‌ها می‌شد.
دواپس با ایجاد یک فرهنگ مشترک و استفاده از ابزارهای خودکارسازی، این شکاف رو پر می‌کنه. در فرهنگ دواپس، توسعه‌دهندگان و مهندسین عملیات با هم همکاری نزدیکی دارند تا اطمینان حاصل کنند که نرم‌افزارها نه‌تنها به سرعت توسعه پیدا می‌کنند، بلکه به‌راحتی و با اطمینان در محیط‌های عملیاتی نیز اجرا میشن.
مزایای دواپس چیه؟
-
سرعت بیشتر در تحویل نرم‌افزار: با استفاده از دواپس، شرکت‌ها می‌تونن نرم‌افزارها رو با سرعت بیشتری به بازار عرضه کنن.
-
کیفیت بالاتر: خودکارسازی تست‌ها و نظارت مستمر باعث میشه که نرم‌افزارها با کیفیت بالاتری تحویل داده شوند.
-
قابلیت اطمینان: با استفاده از روش‌های CI/CD و نظارت مستمر، نرم‌افزارها با قابلیت اطمینان بیشتری اجرا میشن.
-
همکاری بهتر: دواپس باعث بهبود همکاری بین تیم‌ها و کاهش تنش‌ها و اختلافات میشه.
-
کاهش هزینه‌ها: خودکارسازی و بهبود فرآیندها باعث کاهش هزینه‌های عملیاتی و افزایش بهره‌وری میشه.
چالش‌های دواپس
-
تغییر فرهنگ سازمانی:پیاده‌سازی دواپس نیاز به تغییر فرهنگ سازمانی داره که ممکنه برای برخی شرکت‌ها چالش‌برانگیز باشه.
-
نیاز به مهارت‌های جدید:دواپس نیاز به یادگیری مهارت‌های جدیدی مثل خودکارسازی، مدیریت زیرساخت به عنوان کد و استفاده از ابزارهای CI/CD داره.
-
پیچیدگی فناوری:استفاده از ابزارها و فناوری‌های دواپس ممکنه در ابتدا پیچیده به نظر برسه.
به‌طور کلی، دواپس یک فرهنگ و مجموعه‌ای از روش‌هاست که به شرکت‌ها کمک می‌کنه تا نرم‌افزارها رو با سرعت، کیفیت و قابلیت اطمینان بیشتری تحویل بدن. این فرهنگ بر همکاری، خودکارسازی و بهبود مستمر تأکید داره و با استفاده از ابزارهای مناسب، می‌تونه به شرکت‌ها کمک کنه تا در دنیای رقابتی امروز موفق‌تر عمل کنند. هرچند پیاده‌سازی دواپس ممکنه چالش‌هایی به همراه داشته باشه، اما مزایای اون به قدری قابل توجه هستن که بسیاری از سازمان‌ها رو به سمت پذیرش این فرهنگ سوق داده.
پس SRESite Reliability Engineering چیست؟
خیلی اوقات واژه‌های Site Reliability Engineerمهندس قابلیت اطمینان سایت و Devops Engineerمهندس دواپس به‌جای هم استفاده میشن، ولی در واقعیت تفاوت دارن. در واقع SRE فردی هست که وظیفه‌ش بالا بردن اعتمادپذیریReliability، دسترسی پذیریAvailability و کمک به بهبود عملکرد سیستمه.
این کلمات پاراگراف بالا یعنی چی؟
-
اعتمادپذیری: این کلمه در واقع بیان‌گر یک احتماله و با درصد نشون داده میشه. اعتمادپذیری به توانایی یک سیستم برای انجام وظایفش به‌طور صحیح و بدون خطا در یک بازۀ زمانی مشخص اشاره داره. یعنی در واقع سیستم باید بتونه به‌طور مداوم و پایدار کار کنه و نتایج مورد انتظار رو تولید کنه.
-
دسترسی‌پذیری: این کلمه هم مثل قبلی یه احتماله. دسترسی‌پذیری به میزان در دسترس بودن سیستم برای کاربران در زمانی که به آن نیاز دارند، اشاره داره. این مفهوم نشون میده که سیستم، چه‌مقدار از زمان کلی خودش رو در حالت عملیاتی و قابل‌استفاده می‌گذرونه.
وظایف مهندس Devops چیه؟
مهندس دواپس باید بتونه یه زیرساخت خوب برای شرکت فراهم کنه و بعدش ازش نگهداری کنه. لزوماً هم این کارها یک‌نفره انجام نمیشن و گاهی یک تیم DevOps باید روش کار کنه.
زیرساخت خوب یعنی چی اصلاً؟
زیرساخت خوب زیرساختیه که:
-
هر اتفاقی توش بیفته، تحت هیچ شرایطی کاربرها اختلالی حس نکنن. (که البته حرف سنگینیه و نمیشه ٪۱۰۰ تضمین داد که همچین اتفاقی نمی‌افته.)
-
قابل‌گسترش باشه. یعنی به‌صورتی پیاده‌سازی بشه که اگر فردا، شرکت گسترش پیدا کرد و خواست صدها محصول دیگه تولید کنه، بتونه به راحتی اون‌هارو کنار زیرساخت فعلی مستقر کنه. (منظور از محصول، محصولات نرم افزاریه! نه مثلاً قاشق، چنگال)
-
همه‌چی مشخص و مستند باشه. یعنی اگر نیروی جدیدی به شرکت اضافه شد، بتونه به‌راحتی با زیرساخت ارتباط بگیره و بفهمه چه خبره. برای این‌کار نیاز به Iac داریم که پایین‌تر توضیح میدم.
-
خطاهاش از هم مستقل باشن. یعنی مثلاً اگر اعتبار سیستم ارسال SMS مون تموم شد و سیستم پیامک‌دهی دیگه کار نمی‌کنه، اختلالی توی سیستم ورود به پنل کاربری به وجود نیاد، چون ربطی به هم ندارن!
-
همه‌چیزش خودکارسازیAutomate شده باشه. زیرساخت سیستم باید به‌صورت خودکار فعالیت کنه، تغییرات جدید رو به‌روز کنه، تعداد سرورها رو کم و زیاد کنه و…
وقتی سیستم از یه حدی بزرگتر میشه، انجام دادن بسیاری از کارها به صورت دستی خیلی کار سختی میشه. مثلاً یه برنامه‌نویس می‌آد رنگ یه بخشی از سایت رو از آبی به قرمز تغییر میده! آیا واقعاً نیازه یه مهندس دواپس بیاد کد رو از اول build و اجرا کنه و ببره روی سرور؟ آیا ابزاری وجود نداره که این کارها رو برامون انجام بده؟ قطعاً وجود داره و باید در زیرساخت شرکت‌ها پیاده سازی بشه.
زیرساخت به عنوان کد یا IacInfrastructure as Code چیست؟
یکی از مسئولیت‌های مهم مهندسین دواپس، انجام دادن کارها به صورت کدمحوره. ما می‌تونیم به‌راحتی بریم از هر جایی سرور بخریم، روش کلی پکیج نصب کنیم، کلی کانفیگ و هزاران کار دیگه انجام بدیم. حالا اگر دو سال دیگه برگشتیم و خواستیم همین کارهارو انجام بدیم، ولی یادمون نبود چی‌کار کرده بودیم چی؟ اگر عضو جدیدی به تیم اضافه شد، باید همه چی رو دونه دونه براش توضیح بدیم؟ اگر بخوایم زیرساخت‌مون رو تغییر بدیم و بریم از یه جای دیگه سرور بخریم، دوباره باید همۀ کارها و کانفیگ‌هایی که انجام دادیم رو از اول انجام بدیم؟
این‌جاست که ابزارهایی مثل Terraform Ansible و Helmchart values به کمک‌مون میان. با استفاده از این ابزارها کافیه یه سری فایل بنویسیم و داخل‌شون مشخص کنیم چه چیزهایی می‌خوایم. بعد اون‌ها همین کارها رو برامون انجام میدن، بدون این‌که ما در کارشون دخالتی داشته باشیم. با این‌کار اگر زیرساخت جدیدی بخریم، فقط همین کدها رو اجرا می‌کنیم. اگر عضو جدیدی بیاد، فقط همین کدها رو می‌خونه. هر وقت نیاز داشته باشیم هم می‌تونیم برگردیم ببینیم چی‌کار کردیم.
لازمۀ همۀ این‌ها هم اینه که کاری رو دستی انجام ندیم. وگرنه برمی‌گردیم می‌بینیم یه چیز این وسط کمه که باز هم هیچ‌کس نمی‌دونه چی بوده :))
داکرDocker چیه؟
وقتی صحبت از برنامه‌ها یا application ها میشه، هزاران خط کد و نیازمندی‌ها و وابستگی‌ها خودشون رو نشون میدن. این مفاهیم فقط در حوزۀ برنامه نویسی مطرح هستن و یک مهندس دواپس که می‌خواد این برنامه‌ها رو روی سرور مستقر کنه و تحویل مشتری بده، نیازی به درگیر بودن باهاشون نداره. از سال ۲۰۱۳ یه ابزاری به زبان Golang و به نام داکر نوشته شد که فلسفه‌ش ایزوله‌سازی برنامه‌ها از هم‌دیگه و اجرای راحت اون‌ها در هر فضایی بود. داکر با استفاده از کانتینرContainers می‌آد برنامه‌هامون رو اجرا می‌کنه. حالا این یعنی چی؟
ببینید وقتی شما داکر رو نصب می‌کنین، یه Engine باهاش نصب میشه که این Engine تقریباً همه‌جا ثابته. یعنی داکری که من روی سیستم خودم نصب می‌کنم، با اونی که روی سرور (و خیلی فضاهای دیگه) هست، تقریباً یکیه. این باعث میشه من مطمئن شم که اگر یه کدی روی سیستم من با استفاده از داکر اجرا میشه، روی یک سیستم دیگه هم قطعاً اجرا میشه، چون Engine مون یکیه.
مراحل کار با داکر چیه؟
۱. اول شما یه برنامه‌ای، به هر زبانی که دوست دارید می‌نویسید.
۲. بعد با استفاده از داکر اون رو build می‌کنین. خروجی این مرحله اصطلاحاً یه ایمیجImage هست. فرض کنین یه چیزی روی CD نوشتین و همه‌جا می‌تونین ببریدش، به هر دستگاهی بزنین و اجراش کنین. پس اون کد رو build می‌کنین و حالا یه ایمیج دارید که حاوی کد شماست، ولی خب نمی‌دونین توش چه خبره! نیازی هم ندارید که بدونید. چون دیباگ‌هاتون رو انجام دادید و مطمئنید کار می‌کنه. صرفاً می‌خواین ببرین روی سرور یا هر دستگاه دیگه‌ای اجراش کنین.
۳. حالا که ما یه ایمیج آماده برای اجرا داریم، کافیه اجراش کنیم. بعد از این‌که اجراش کردیم، یه مفهومی به اسم کانتینر ایجاد میشه. در واقع کانتینرها فضاهایی برای اجرا شدن ایمیج‌ها هستن. حالا کد ما در حال اجراست و می‌تونیم مثل قبل باهاش کار کنیم. اما فایدۀ این کار چی بود اصلاً؟
فایدۀ داکر چیه؟
تا این‌جا فهمیدیم که برنامه‌هامون در واقع در کانتینرهایی اجرا میشن. نکتۀ مثبت داکر این‌جاست که این کانتینرها از هم مستقل هستن. استقلال و ایزوله بودن این کانتینرها نسبت به هم‌دیگه به ما این امکان رو میده که بتونیم به‌راحتی، همه‌جا اجراشون کنیم.
حالا خطاهاشون به هم‌دیگه ربطی ندارن و از هم‌دیگه کاملاً جدا هستن. از طرف دیگه، یک مهندس دواپس درگیر کد نیست و کاری به هزاران خط کد و نیازمندی‌هاش نداره و صرفاً با ایمیج‌های داکر طرفه. بزرگترین مزیت داکر برای مهندسین دواپس، عدم درگیری‌شون با کده. مدیریت و نگهداری ایمیج‌ها که صرفاً انتزاعی (abstraction) از هزاران خط کد هستند، بسیار راحت‌تره.
کوبرنتیزKubernetes چیه؟
حالا که ما کد هامون رو به صورت ایمیج در‌آوردیم و شروع کردیم به اجرا کردن‌شون، نیاز به یه ابزاری داریم که بتونیم این کانتینرهای در حال اجرا رو مدیریت کنیم. بعضی وقت‌ها برنامه‌ها با خطاهایی مواجه میشن.
و Crash می‌کنن. بعد از خرابی چه مکانیزمی باید در پیش بگیریم؟
همۀ این کارها و سناریوها با کوبرنتیز قابل‌مدیریت هست که ابزار بسیار پیچیده‌ای هست و یادگیری‌ش اصلاً به همین آسونی‌ها نیست. برای همین بیشتر از این توضیح نمی‌دم. اگر دوست داشتید، درباره‌ش بیشتر بخونین :))
دیگه تو دواپس چیا نیازه؟
یکی از مهم‌ترین مفاهیمی که وجود داره، مشاهده پذیریObservability هست. ابزارهای monitoring به ما این قابلیت رو میدن که حواس‌مون به همه‌جای سیستم باشه و بتونیم رفتار سیستم رو دائماً رصد کنیم. سه مفهوم خیلی جدی در رصد کردن رفتار سیستم وجود داره:
Trace: تریس‌ها به ما کمک می‌کنن تا بفهمیم وقتی یه درخواستی وارد سیستم‌مون میشه، چه مراحلی رو طی می‌کنه تا خارج بشه، و این‌که در هر مرحله چه‌قدر کارش طول کشیده. این‌جوری می‌تونیم بفهمیم کجاهای سیستم‌مون کنده و داره رفتار غیرعادی نشون میده. مثلاً درخواستی از طرف کاربر اومده که می‌خواد سبد خرید بسازه، پرداخت کنه و محصول براش فرستاده بشه. با رصد کردن این فرآیند می‌تونیم بفهمیم که مثلاً فرآیند ساخت سبد خرید بسیار کند انجام شده و مشکل رو رفع کنیم.
Log: لاگ‌ها در واقع اون اتفاق‌هایی هستن که در برنامه‌های شما می‌افتن. وقتی یه برنامه‌ای ارور میده، اونو توی لاگ خودش می‌نویسه. ما با بررسی این لاگ‌ها می‌تونیم بفهمیم در طول زمان چه اتفاقی برای چه بخشی از سیستم‌مون افتاده. به‌خصوص توی سیستم‌های بانکی این لاگ‌ها به شدت مهم میشن و ما باید ازشون backup بگیریم. در سیستم‌های مالی حساس باید این اتفاقات ثبت و نگهداری بشن که چه کسی در چه زمانی چه کاری انجام داده، چون هر لحظه ممکنه نیاز بشن. به قول یه عزیزی که می‌گه ممکنه ادارۀ اطلاعات با یه گونی بیاد، اگه لاگ داشته باشین لاگو می‌بره، وگرنه خودتونو می‌بره.
Metric: متریک‌ها یک‌سری شاخص هستن که فواید بسیاری دارن، ولی خب پایه‌ای‌ترین استفادۀ اون‌ها در بررسی وضعیت CPU سرورها و مصرف RAM و… هست. نیازه که ما این شاخص‌هارو از سرورهامون جمع آوری کنیم و بعد حواس‌مون بهش باشه که چیز غیرعادی در اون به‌وجود نیاد.