吐槽一些技術想法和事情

最近其實已經琢磨了不少的事情，有時候恨不得是十分鐘幹九件事情，但是我還是有些不滿意，因為我似乎很多事情沒有按照計劃來做。所以我要吐槽一下。
先來吐槽軟文
最近在朋友圈裡看到不少的技術文章，有不少每每讀完都有種讓人傷神的感覺，因為有些文章看起來標題很豐富，但是看內容想看最後的結論，找不到，與其這樣還不如多看幾個段子給自己消遣消遣。有些文章看起來標題樸實，但是內容著實很豐富，這種文章畢竟是少數，我欽佩這樣的文章，乾乾淨淨，樸樸實實，做技術就是技術的樣子，不要帶有太多的商業色彩，有些文章也確實有點貨，但是讀著讀著感覺被帶入了另一扇門，最後也會有點迷失的感覺，我有時候就很奇怪這樣的文章，直到有一天聽人說到軟文這麼一個概念，我才恍然大悟。這樣一看我就看透了。然後也在偶爾會接到某某商家的電話，說想和我進一步洽談，根據流量轉發情況進行分成，堅持了幾百天了，如果能有好的文章融入，著實是一件好事，不收錢也願意接受，如果還有點外快，那就更提神了。但是他們在接觸之後會發來一些連結，看著那些文章，就是完完全全的廣告，這種的內容發出去，估計沒幾天大家就都取消關注了。現在我也不去主動推薦自己的公眾號了，一種原因是感覺現在的好文章太多，拿不出手了，不能僅僅靠一個幾百天的堅持來說明什麼了，而且本身也說明不了什麼。另一方面我想好好做自己的事情，給自己多一些空間和時間，因為自己目前也在做社群，其實有很多東西發現都是需要慢慢沉澱的，可能在某一天就會發現自己進步了一大截，我想看到自己默默成長的軌跡，在這個過程中會有很多的朋友來提問打氣，已經足夠了。而且現在著實沒有那麼多的精力了，有時候白天會把手機放在一旁，過很久才來看看手機。所以吐槽了一圈，還是要保持自己的風格，軟文堅決不要，好的文章就不遺餘力推廣，無論是哪個社團，組織，在公眾號裡這就是我的小窩，我還能決定自己希望做的事情。
然後是關於運維管理自動化
最近總能聽到各種運維經驗之談，總結攻略，包括我自己也在嘉年華上做了運維的一些經驗分享，從我的觀點來看，現在很多人都在推行自動化運維，我覺得可以再慢一些。首先看著別人做了多大的平臺，多豐富的功能，多健全的維度等等。我覺得都是按需定製，別人的好不一定在你這邊可行，別人的經驗有很多到了你這邊可能因為環境業務不通，感覺無從參考。那麼這個時候就是參考這個理念了，很多功能都是逐漸完善，或者就專注於一個很小的模組，把它做好了做精了，比一個設計臃腫，已成體系然後再大刀闊斧改動的系統要好得多。
然後說自動化運維，自動化運維現在完全需要那麼自動化嗎，我覺得目前來看，至少從我的角度來看還麼有那麼多的場景確實需要，比如主備自動切換，技術肯定可行，那麼自動化要這麼動嗎，我覺得很多場景實際上不需要這樣，與其專注於這一方面，還不如更多關注於前期的更多監控最佳化管理。從本質上減少這種錯誤的機率。
現在的很多運維經驗從我的觀點來看都是從系統層面來入手，感覺還是缺少了很多應用層面的東西，當然一說應用就是具體的場景了，那麼這些具體的場景也有一些通性。有些還是可以互相參考借鑑的。我看現在的很多運維管理工具就真是偏向系統的，其實完全可以考慮很多應用的功能，我之前的工作環境中應用運維的工作就做得非常徹底，只是公司比較低調而已，而現在的很多公司的產品相比，其實要考究的多，都說現在sql稽核非常重要，sql規範非常重要，很多時候我們發現都是在後期了，那麼這些問題看起來確實都是開發導致的，那麼回過頭來，對於開發來說，他肯定壓根不需要知道哪個表所屬的表空間，表中的約束名等等，這些如果從前期規劃都是完全可以避免的。比如我們之前就是所有的開發語言都會有一個統一的db入口，任何的db變更，初始化都會從這個入口來完成，至於約束名，表空間等等這些都會有對應的配置匹配。有了這些基準，後期的管理和維護就會容易的多，比如分多版本，多模組，大體也會在這個框架之內，不會亂來，那麼有了這些基礎的制約，sql稽核的工作就非常有限了，從我的感覺來看更多都是sql最佳化的部分，語法錯誤這種問題基本沒有見過。我們也沒有推行sql稽核工具，照樣可以做得很好。
如果覺得這些還聽起來就那麼回事，那麼開發同事可以自主匯入匯出資料，可以自己完成備份，環境升級，環境補丁的部署都可以由開發同學自主完成，這些就不用我們做太多的干預，那麼應用的運維需要不需要？所以這些問題再追根溯源，還是能夠從初始化開始就能避免很多的問題，那麼這些應用的工作都做得很好了，dba幹嘛呢，做更有價值的工作。
今天和前阿里的哥們聊天，有一點就很好，關於資料庫效能測試中的rt就是基於應用得到的一個值，這些測試基準基於完全真實的應用場景會更有說服力更有意義，哪些iops,tps之類的指標在脫離業務之外裸奔的資料還是站不住腳的，所以還是需要關注業務，這也是我在嘉年華中的運維工作中特別提到一部分業務和開發。我的用意就在此。
最後說說資料庫中的技術問題
今天聽同事講資料庫儲存的內容，當然內容也是常規的部分，但是換做以前的我，也是感覺脫離不了這些圈圈範圍。儲存再能在oracle範圍內將出點什麼來，還不如哪些基本的概念和知識點，有時候我們可以反問一些，為什麼在oracle中會這麼實現，有沒有其它的參考，其實可以的。很多的東西都可以去參考作業系統層面你的實現，比如作業系統層面有外存記憶體，外存的管理和資料庫的物理管理有些類似，記憶體的部分和資料庫中的記憶體管理有些類似，那麼關於儲存管理，多說一點就是作業系統裡的初始概念，固定分割槽，可變分割槽，分頁等等，這些其實都在Oracle中似乎能夠看出一些痕跡，在Oracle中聽起來很高大上的mutext概念，如果翻看作業系統層面的概念，本身這個概念就已經很早就提出來了。都有一些參考和借鑑之處，比如關於區段的本地管理，使用了點陣圖的方式，那麼作業系統層面還有哪些可以借鑑的東西，光演算法就已經很多了，最佳適應演算法，最先適用演算法，點陣圖法，其實多瞭解一些還是對於我們理解oracle有很多的益處的。

所以吐槽歸吐槽，技術歸技術，真是一碼歸一碼，把自己的一畝三分地搞透了，搞明白了，其實本身就是一件很有價值的事情。