ARTS的初衷

• Algorithm：主要是為了編程訓練和學習。每周至少做一個 leetcode 的算法題（先從Easy開始，然后再Medium，最后才Hard）。進行編程訓練，如果不訓練你看再多的算法書，你依然不會做算法題，看完書后，你需要訓練。關于做Leetcode的的優勢，你可以看一下我在coolshell上的文章 Leetcode 編程訓練 - 酷 殼 - CoolShell。
• Review：主要是為了學習英文，如果你的英文不行，你基本上無緣技術高手。所以，需要你閱讀并點評至少一篇英文技術文章，我個人最喜歡去的地方是http://Medium.com（需要梯子）以及各個公司的技術blog，如Netflix的。
• Tip：主要是為了總結和歸納你在是常工作中所遇到的知識點。學習至少一個技術技巧。你在工作中遇到的問題，踩過的坑，學習的點滴知識。
• Share：主要是為了建立你的影響力，能夠輸出價值觀。分享一篇有觀點和思考的技術文章。

作者：陳皓
鏈接：https://www.zhihu.com/question/301150832/answer/529809529
來源：知乎
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。

Algorithm

給定一個整數數組 nums 和一個目標值 target，請你在該數組中找出和為目標值的那 兩個 整數，并返回他們的數組下標。
你可以假設每種輸入只會對應一個答案。但是，你不能重復利用這個數組中同樣的元素。
示例:
給定 nums = [2, 7, 11, 15], target = 9
因為 nums[0] + nums[1] = 2 + 7 = 9
所以返回 [0, 1]
來源：力扣（LeetCode）
鏈接：https://leetcode-cn.com/problems/two-sum
著作權歸領扣網絡所有。商業轉載請聯系官方授權，非商業轉載請注明出處。

使用字典hash的方式，縮短查找目標元素的時間，有點取巧。

class Solution:
    def twoSum(self, nums: List[int], target: int) -> List[int]:
        nums_index = {}
        for i in range(len(nums)):
            nums_index[nums[i]] = i
        for i in range(len(nums)):
            num2 = target - nums[i]
            j = nums_index.get(num2)
            if j and i != j: #需要注意i和j不能相等，因為不能重復利用
                return [i, j]

Tip

1. 使用ldd確認庫文件依賴路徑是否有問題

ldd <file>可以看到庫文件的鏈接情況，用來幫助排查依賴庫缺失的問題。ldconfig可以用來重新生成動態鏈接庫的緩存/etc/ld.so.cache，輸出結果是有加載順序的。

 linux-vdso.so.1 => (0x00007fffbb763000)
 libcudart.so.10.0 => /usr/local/cuda/lib64/libcudart.so.10.0 (0x00007fa9ef69a000)
 libcublas.so.10.0 => /usr/local/cuda/lib64/libcublas.so.10.0 (0x00007fa9eb104000)
 libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fa9eaee7000)

2. 使用strace分析進程執行耗時，追蹤程序問題

https://linuxtools-rst.readthedocs.io/zh_CN/latest/tool/strace.html

Review && Share

https://landing.google.com/sre/
What is SRE? Hear from our SREs
視頻中講了很多谷歌的SRE對于SRE工作的理解，回答了一些網友的提問（很多也是我的疑問）。正式工作了16個月了，title是SRE，最近卻覺得干的活是打雜，sigh~，我需要好好想想自己的處境，想想怎么改變現狀，想想自己的成長，不能就真的一直“打雜”下去啊。
視頻中關于SRE的事情，其實在《SRE Google運維解謎》這本書中都有提到，不過我做了歸類整理和自己的日常工作進行對比。

What do SRE do?

自動化和消滅瑣事（Toil）

1. 自動化不是腳本化，如果整個流程中引入了人工確認，就會引入人工操作失誤的風險，導致整個流程的執行效率變低；
2. 不只是承擔瑣事，也要去消滅瑣事，一個人能cover住的運維瑣事是有限的，如果不通過自動化工具減少，會導致overload；
3. 瑣事（包括oncall）的比例不高于50%，如果一個服務頻繁報警，導致SRE需要經常人肉運維；那么就需要重新審視整個服務的穩定性狀況和SLO了，對于不穩定的服務需要投入人力去提示其穩定性；SLO如果設置太高導致頻繁報警，就適當調整SLO；對于達不到SRE運維要求的服務，SRE可以選擇退出該服務的運維支持（這需要SRE有足夠多的話語權）

這些東西在我的日常工作中也有遇到，然而最近半年多有這么一直趨勢，我就算是在非oncall時間，也會被各種瑣事包圍，有些是必要的（我稱之為必要瑣事，例如業務邏輯梳理、報警覆蓋梳理，但是這部分工作也因為需求變化的問題，導致重復梳理），有些是可被自動化或者干脆就是人肉填系統流程的坑（這些是可以被自動化消滅的Toil，例如服務手動縮容降配、SSH相關問題、工單執行失敗處理、CMDB數據修正、其他值班人未及時相應的需求等等）。“必要瑣事”是我是可以接收的，在熟悉之后，業務相關的梳理成本是可控的。“Toil”瑣事是我想要消滅的，然而現在的問題的，最近半年來，我的大部分精力，甚至包括很多加班的時間，都越來有多地被牽制在人肉處理瑣事上，我反而沒有精力去自動化瑣事，去消滅瑣事了！

關于oncall

1. 技術支持、服務器配置錯誤、報警處理、工單處理等等工作，這些工作谷歌并沒有什么黑客氣讓它們消失了，只是用各種方法將它們的處理成本降低到了可接受范圍內。

區別就在于oncall的壓力吧，1）因為報警處理自動化、監控準確性、報警準確性等等基礎設施不夠完善，導致oncall的壓力是很大的，sla報警可能經常觸發，甚至導致“狼來了”效應，就像現在大數據相關服務的sla報警我已經習慣了；2）內部平臺像是發布系統、工單系統、SSH權限等等多多少少會有小毛病，這些問題的支持很耗人；3）報警或問題發生之后的處理手段也不夠好用，像是最近頻繁出現的單實例問題，都是靠人肉重啟去解決的，而且問題有越來越多的趨勢，然而卻沒看到哪個團隊在重點解決，似乎人肉cover住就可以先不管了；4）因為害怕故障發現不及時，同時還在接收很多業務報警、系統底層報警，但是因為業務報警的策略調整權在業務方

關于故障處理

1. post-mortem，事后故障復盤
2. 對事不對人，建立故障應急處理流程

這部分是我們團隊一直在做的，故障復盤、故障監控發現率建設、故障todo跟進；但是因為故障是和KPI掛鉤的，大家在處理故障時，還是會不知不覺跑偏到到底是誰的鍋這個問題上，尤其是沒有立刻現場復盤的故障。

SRE成為不同團隊建的紐帶

1. SRE對公司內部的各種工具、輪子接觸的比較多，能夠幫助不同團隊之間的工具傳播

這個是事實，不過并沒有作為一件事情來做，就像我對公司內部的服務發現、監控配置、壓測平臺、發布系統等等工具都是比較熟悉的，平常也會去幫助解答RD的這塊疑問。但是，因為時間精力問題，很多細節的東西沒有去深入了解，沒法在這件事上獲得更多收益。

What kind of coding do a typical SRE do?

1. 沒有typical SRE，不同方向的SRE做的coding差別很大；
2. 故障預測，容量水位。也即現有監控數據的基礎上，完善自動化監控；
3. DBA SRE，協助開發相關系統，這塊沒太聽明白，算是比較專的領域；
4. 自動化配置，內部系統優化，這也是消滅瑣事的一部分；

Coding部分對負責不同崗位的SRE來說是不一樣的，硬要從技術難度上做區分，差別也很大，相通點就是在用代碼解決運維問題吧。
這部分是我最想做的事情，卻也是目前最少做的事情。我希望看到的世界是這樣的，我在做一線運維工作，我是這個系統的直接使用者，我向其他團隊推廣這個系統，如果碰到了問題，我能夠（有權利、有時間、有能力）去修復這個問題；而不是像現在這樣，靠人工接入人肉維護系統的正常運轉（包括CMDB、SSH授權、發布系統），卻沒有時間去做修復的事情，這就好像整個團隊中的臟活累活我們包了，但是背后可以有成長、有收益的活卻沒有精力去做，只能拱手讓人，這樣真的會讓人找不到成就感，找不到價值感。
我不想這樣，我不要這樣。