10 روشی که شما مهندسان DevOps خود را دیوانه می کنید

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

1. هر سوالی که می توانید در گوگل بپرسید

برخی از سوالات ممکن است آنقدر خاص باشند که نیاز به تخصص خاصی داشته باشند. در مواقع دیگر، ممکن است به کسی نیاز داشته باشید که اطلاعات فنی پیچیده را به گونه‌ای توضیح دهد که درک آن آسان‌تر باشد. اما درصد زیادی از سوالاتی که از مهندسان DevOps می‌پرسند را می‌توان توسط Google، Reddit، Quora یا Stack Overflow پاسخ داد. پرسیدن سوالاتی که بتوان آنها را در گوگل جستجو کرد نه تنها ناامید کننده است، بلکه برای بهره وری DevOps نیز مضر است. کار آنها به تمرکز زیادی نیاز دارد. و هر زمان که شتاب آنها را قطع کنید، آنها را مجبور می کند که زمینه را تغییر دهند و روی چیز دیگری تمرکز کنند. در نتیجه، سؤال شما نه تنها برای پاسخ دادن، بلکه برای سوئیچ زمینه نیز زمان می برد. بسته به شخص، این تغییر در تمرکز می تواند بین پنج تا بیست دقیقه طول بکشد. بنابراین فرض کنید پاسخ سوال شما پانزده دقیقه طول می کشد، شما اکنون بین بیست تا سی و پنج دقیقه از زمان مهندس DevOps خود را تلف کرده اید. مطمئن شوید که سوال شما ارزشش را دارد. گوگل را دوبار و سه بار بررسی کنید تا ببینید آیا پاسخ های موجود در آنجا کافی هستند یا خیر. و اگر همه چیز شکست خورد، مهندس DevOps شما برای کمک به شما آماده است، اما او قطعا از تحقیقات قبلی شما قدردانی خواهد کرد. ; )

2. هدایت سوالات به شخص اشتباه

آیا کاملاً مطمئن هستید که سؤال شما توسط یک مهندس DevOps بهترین پاسخ داده می شود؟ اغلب اوقات، مهندسان DevOps با سؤالاتی مواجه می شوند که به تخصص آنها مرتبط نیست. این سوالات ممکن است برای یک معاون تحقیق و توسعه، شخص فناوری اطلاعات یا مهندس نرم افزار مناسب تر باشد. بنابراین قبل از اینکه بپرسید، با همتایان خود بررسی کنید که تیم DevOps شما افراد مناسبی هستند که باید به سراغ آنها بروید.

3. بررسی نکردن کد خود

کارهای زیادی برای انجام دادن دارید اما مهندس DevOps شما نیز همینطور است. او وظیفه دارد همه چیز را از CI/CD و توسعه ویژگی‌های جدید گرفته تا مدیریت زیرساختی که محصول شما روی آن اجرا می‌شود، انجام دهد. وادار کردن آنها به بررسی کد شما علاوه بر همه چیزهای دیگر در ظرف خود کار جالبی نیست. بنابراین قبل از اینکه کد خود را به DevOps فشار دهید، مطمئن شوید که آن را آزمایش کرده اید، آن را برای اشکالات بررسی کرده اید و کد را به طور کامل بررسی کرده اید. قبل از اینکه کد را آزمایش کنید، با آزمایش عملکرد پایه شروع کنید، سپس به بررسی همتایان، تست استاتیک برای آسیب‌پذیری‌های امنیتی، تست واحد و عملکرد و در نهایت QA بروید. از این گذشته، هیچ چیز بیشتر از رفع کد معیوب شخص دیگری بر روی اعصاب DevOps تأثیر نمی گذارد.

4. گفتن “آیا شما فقط می توانید این یک کار کوچک را انجام دهید؟”

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

5. تنظیم جلسات بی فایده

اگر تا به حال متوجه هر الگوی شده اید، این است، مهندسان DevOps از اتلاف وقت متنفرند. بنابراین اگر آن جلسه می توانست یا باید یک ایمیل باشد، بهتر است آن را به همین صورت ترک کنید. چگونه متوجه می شوید که جلسه ضروری نیست؟ اگر این یک مکالمه بسیار پیچیده نیست، چیزی که نیاز به برنامه ریزی، بحث یا تدارکات زیادی دارد، احتمالاً ارزش تشکیل جلسه در مورد آن را ندارد. در زمان، تلاش و ناامیدی خود صرفه جویی کنید. دفعه بعد، فقط آن را از طریق ایمیل یا Slack ارسال کنید.

6. گفتن “ما اکنون به این نیاز داریم.. فوری است”

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

9. خودکار نکردن وظایف روتین

بسیاری از وظایف DevOps می‌توانند و باید خودکار شوند. چه در مورد مدیریت پیکربندی با ابزارهایی مانند Chef یا Puppet صحبت کنید، یا از اتوماسیون استقرار با ابزارهایی مانند Jenkins، اتوماسیون برای DevOps اهمیت کلیدی دارد زیرا بسیار کارآمد است و مهندسان DevOps را قادر می‌سازد بر روی کارهایی تمرکز کنند که به قدرت مغز بیشتری نیاز دارند و کارهای بیشتری را به ارمغان می‌آورند. ارزش برای کاربران هر چیزی که می تواند خودکار باشد، باید خودکار باشد. بنابراین اگر ماشینی می تواند آن را بهتر انجام دهد، مطمئن شوید که روی اتوماسیون سرمایه گذاری کرده اید. مهندسان DevOps شما از شما تشکر خواهند کرد.

10. عدم یکپارچگی بین ابزارها

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

کلمات پایانی

DevOps به هیچ وجه کار آسانی نیست. در اکثر مواقع، مهندسان DevOps از جنبه های چالش برانگیز نقش های خود لذت می برند، به جز زمانی که صحبت از موارد تشدید کننده ذکر شده در بالا باشد. بنابراین، اگر با یک مهندس DevOps کار می‌کنید، زندگی آنها (و شما) را با درک ناراحتی‌های  آنها و اطمینان از وقفه‌های کمتر ممکن آسان‌تر کنید. 

منبع : https://zesty.co/blog/10-habits-devops-hate/