運維交接的一些理解

qc1iu 發布于2019-05-28 17:12 / 2244人閱讀

摘要：前言最近部門變動，負責接手電商業務的運維工作，但是電商原來運維人員人，我只有人，因此這個交接工作還是挺有難度和壓力的，已經交接完畢，我想這些經驗對于新工作新環境新業務都有所幫助，也是自己的運維足跡，記錄一二跟產品運營了解業務由于以前沒有接觸

前言:
最近部門變動，負責接手電商業務的運維工作，但是電商原來運維人員6人，我只有1人，因此這個交接工作還是挺有難度和壓力的，已經交接完畢，我想這些經驗對于新工作、新環境、新業務都有所幫助，也是自己的運維足跡，記錄一二

跟產品運營了解業務

由于以前沒有接觸過電商的運維，因此首先了解電商業務，梳理為以下

電商產品詳情

電商功能模塊

電商節假日活動

用戶登錄、瀏覽、下單、支付流程

是否有搶購秒殺類業務

優惠券紅包積分等業務

會員業務

以上業務最好跟產品、運營去了解，他們是比較清楚的，對這些清楚了之后才能開展之后的運維工作

跟研發了解系統架構

跟開發聊聊業務架構，了解所使用的技術，為什么使用，以及好處。最好讓其準備PPT能演講下，如果不行讓其發發文檔看看也是好的，梳理以下幾點

了解各項目業務架構設計，及拓撲圖

大流量場景業務

目前存在的業務瓶頸

有無歷史遺留落后設計

有無應用最新技術及為什么這樣選擇

在這里只是了解，運維跟研發是會一直合作的，因此后面可以帶著問題再找到相關負責人

運維相關

這里就涉及到我們的主要工作了，了解運維的方式，技術棧等等，列了如下

了解閱讀運維文檔，一般有wiki，因此可以先看看大致了解，但不是所有wiki都有章有法，多數還是很亂

了解當前運維資產，服務器、網絡、數據庫等相關運維資源情況

了解當前運維方式，如人肉、腳本、自動化等等，看看當前處于哪個階段

了解當前運維技術棧，畢竟運維技術、工具更新快，且多又雜，不一定都接觸過

了解線下線上發布流程，是否自動化

了解各業務部署的運維架構

了解目前運維安全方面的防護

了解和開發測試運營等合作方式

減少踩坑風險

相信很多人如果接手其他人的工作時，前面都是比較痛苦的，因為其他人的工作方式、理念等都跟自己或多或少都有出入，就運維而言，自己當前的技術能力如果與接手的運維工作階段(如自動化程度較高)有出入，則很難快速著手，比如工作中沒有一定的標準、規范會導致很混亂，或者即使有標準規范，但執行得不理想。又或者工作中都靠口頭相傳，沒有很好的文檔記錄，因此想要快速，首先自身的技術需要有一定的基礎，其次就是努力熟悉了，這里我主要是提出幾點減少踩坑坑的方法

1.做好記錄
如果跟人交接，則一定要做好記錄，這點非常重要，因為人在短時間內接收一大堆東西是非常容易忘記的，俗話說的好，好記性不如爛筆頭，最重要的是自己記錄的過程也會形成一種記憶，可以回想當時為什么這樣記錄幫助回憶，另外很多wiki上找不到的考運維間口頭相傳的更要記錄

2.標準與非標準
現在運維DEVOPS理念很火，但其實好些團隊做得并不完全，有些地方做了標準化，有些地方又保留了老的，導致運維過程中，有些自動化了有些還是人肉，這些需要好好區分開來，否則很容易出故障，當然后續是一定優化這樣的不良運維

3.熟悉各業務所在服務器
首先運維自己也要熟悉產品相關的業務，當我們業務出問題時，才能第一時間處理，比如某個頁面打不開，那么是什么域名，什么業務，可能在哪些地方出故障，我們也要第一時間知道這些業務在哪些服務器上面，這樣才能方面運維排查問題，所以要熟悉業務和服務器間的拓撲圖

4.熟悉各個服務進程的啟動停止方法
在運維里面流行一句話，沒有什么是重啟解決不了的，雖然不那么準確，但是運維工作中，的確有很多時候的故障是可以通過重啟來快速恢復業務的，那么我們不同的服務進程如何重啟一定要優先了解熟悉并記錄，才能做到更快速的管理進程

5.熟悉各個服務的文件配置路徑、日志路徑
運維工作中總會有變動，故障等，當需要修改配置文件，以及查看日志時，如果我們不熟悉則會查詢許久，因此在交接過程中這些也一定要記錄下來，才能快速處理運維需求及故障

6.熟悉了解各個服務器的開機啟動項
開機啟動或者有哪些還沒有加入開機啟動的進程一定要注意，有時候服務器宕機了進程沒有啟動，就影響了業務，因此要去了解如chkconfig、/etc/rc.local里面的內容及未添加的

7.熟悉好發布流程
跟運維及其他部門了解代碼發布平臺、流程等，這是經常用到的，問問有無哪些需要運維經常配合的，還有一些歷史遇到的一些問題

8.了解以往故障
對以前運維中發生的故障如果有記錄那就最好去了解，看看當時的故障表現及處理方法，如果沒有記錄，也可以詢問同事了解

9.對不熟悉的技術棧先淺嘗
運維技術工具眾多，我們一般不會每一種都了解，如果接手的剛好有較多自己不熟悉的，可以先了解，然后知道怎么重啟管理進程以及查看日志排查問題即可，等有富余時間了再逐漸深入學習，這樣才不會消耗大量的時間在一些不熟悉的事情上面

10.優先深入理解核心業務
要跟運維開發測試運營產品等了解哪些是非常核心的業務，是不可容忍停機停服的，這些是我們重點關注并且需要非常熟悉的，需要很仔細的對待交接，千萬不能馬虎

11.搞好關系
沒錯啦，無論是交接還是去了解學習，一定要跟同事們打好關系，可以適當的請客吃飯幾次，這點非常重要，因為在交接的時候，有些坑如果對方不說，你不一定看得到。所謂害人之心不可有，防人之心不可無，大家相處融洽，其樂融融，相信在交接的時候也更愿意將經驗之談奉上，說不定還能多學習些運維知識，提升自己技術水平，還交個朋友，何樂而不為

總結

在防止踩坑哪里都基本總結了，在新工作新環境或者交接工作中一定要放穩心態，戒躁戒急，要自信些，有難度有挑戰有壓力才能看到自身的不足，遇事冷靜則事半功倍，工作加油!!!

云服務器 GPU云服務器服務器交接錯誤的是 java的一些代碼深度學習的一些應用 php實用的一些代碼

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/8098.html

[原創] 如何理解EOS的性能設計 - 主鏈部分

摘要：最近看源碼發現跟之前理解有點出入，目前代碼實現上跟白皮書上也有所出入，該文章需要更新修正前言作為的代表，他的設計是比較超前的，也是目前最被看好的項目之一本文從傳統互聯網碼農思維，嘗試講述下的性能方面的設計本文只是涵蓋了基礎主鏈部分，暫不包括最近看3.0源碼發現跟之前理解有點出入，目前代碼實現上跟白皮書上也有所出入，該文章需要更新修正前言 EOS作為blockchain 3.0的代表...

shenhualong 2019-06-27 18:17 評論0 收藏0
必看！互聯網開發模式的經驗之談

摘要：架構設計實體化單元測試敏捷開發講究要快速的修改代碼，我們往往會發現，代碼修改的越頻繁，越多，這似乎是一個無法解決的矛盾。本文由云+社區發表，作者：韓偉互聯網開發的核心問題當我1999年進入互聯網行業工作的時候，華為剛剛通過了著名的CMM認證。當時作為一個小程序員，非常向往業界經典的軟件開發模式。因為看上去，如果企業實行了CMM，我們程序員就不用再天天為了老板一個拍腦袋的主意而加班...

寵來也 2019-08-23 14:38 評論0 收藏0
必看！互聯網開發模式的經驗之談

摘要：架構設計實體化單元測試敏捷開發講究要快速的修改代碼，我們往往會發現，代碼修改的越頻繁，越多，這似乎是一個無法解決的矛盾。本文由云+社區發表，作者：韓偉互聯網開發的核心問題當我1999年進入互聯網行業工作的時候，華為剛剛通過了著名的CMM認證。當時作為一個小程序員，非常向往業界經典的軟件開發模式。因為看上去，如果企業實行了CMM，我們程序員就不用再天天為了老板一個拍腦袋的主意而加班...

My_Oh_My 2019-07-30 18:44 評論0 收藏0