不知不覺已經從大學將近半年，一直在深圳**公司從事運維工程師的崗位。在上周部門同事的分享會上，講到了許多關于運維方面的東西，特別是思想上，所以想對自己半年的運維工程的工作做一個小小的總結，本來是上周末就想寫點什么，但是部門團建活動，所以就推遲了?？偨Y以思想為主，大神勿噴，歡迎給小菜多一點點建議。

大學的時候，學習了運維方面的一些基礎知識。一到公司被分配到云平臺，不久部門組織架構就進行了調整，接到的第一次任務就是docker容器編排——kubernetes的使用。這東西以前從來沒碰過，也沒有見過，剛開始的時候反反復復的看了很多遍名詞，組件是什么，有什么功能，說實話，看了一周都是云里霧里，kubernetes就是一條充滿荊棘之路，因為kubernetes不是單單的一個東西，它涉及的東西太多，虛擬機技術，docker，cni網絡，ceph存儲等，如果單純的kubernetes發揮的作用不大，說不來，不怕笑話，我們部門就我一個運維，所以熟悉，搭建kubernetes的任務就落到了我這個應屆運維身上，當然還是要感謝導師的幫助，總之，走上kubernetes容器服務之后，我不是在踩坑，就是在坑里。最近公司的容器服務準備投入使用了，基礎功能差不多，但是還是有許多地方值得去改善，對kubernetes的了解雖然多了很多，收獲了很多，但是感覺還是很不夠。

上周，聽同事分享了運維的一些思想，運維和運營，DevOps。運維實際上就是技術運營，平時所叫的運營實際是業務運營，感覺現在的運維不想以前了，開機器，設置網絡等等，現在好像都不需要怎么處理，現在只需要在網站上點點就行了，都覺得運維有一天會失業了，結果是是絕對的，運維不會失業，還是需要運維，只是從分享中了解到，現在的運維的要求更高了，比如：要學會去審核一些上線的代碼，從正式的環境中去分析這些代碼上線后，對業務的影響，用戶的體驗是怎么樣的，變好了還是變差了；可以想一些辦法讓初次使用的用戶在網絡下載等方面有個更好的體驗等等，這都需要，要求我們干運維的去學習更多的東西。DevOps感覺吧，更重要的是一種思想，開發要從運維角度去思考，代碼對環境的影響，運維也要從開發的角度去考慮代碼這些進程，線程的并發，異步等等。現在DevOps主要有三種，第一種是借助開源工作，如ansible，Puppet等；第二種是云平臺，使用docker，拆分微服務；第三種那就是那些高大上，膜拜的AI運維了。