後端開發甩鍋指南
甩鍋，最重要就是技術的方法論。
如果在程式碼質量、後端架構上你有處於鄙視鏈上端的方法論，那麼甩鍋就能易如反掌事半功倍。如果對於軟體工程、專案管理有方法論，那麼你的甩鍋將信手拈來無往不利。
其次，對不同的角色需要有不同的側重。
例如甩鍋物件是產品，那重點應該放在需求和時間上；
如果甩鍋物件是組裡的新人，重點通常是「效能」、「優雅」、「設計模式」；
面對測試，可以講講如何難以實現和如何難以復現；
面對的是同級開發，情況比較複雜，通常可以側重code review；
想要把鍋分擔給運維時可能比較輕鬆，講一講十年前留下來還沒處理掉的基礎設施的bug。如果公司還沒有十年的話，可以談談做壓測和走部署流程有多不方便。
考慮甩給leader，則需要再三謹慎，因為對方很可能掌握著強於你的方法論。
最後，一定需要結合實際情況。
例如，雖然重點是抱怨產品的需求，但千萬不能主動提起「使用者體驗」；再比如，甩鍋給運維提到「機器效能」時，也注意不要犯「給公司省點錢」的錯誤。
下面，就具體情況舉一些例項。
API響應慢：
對測試：只有一/幾個使用者反饋嗎？影響主流程嗎？能穩定復現嗎？
對前端：前端能做快取嗎？能改成輪詢嗎/能改成長連線嗎？有前端日誌嗎？
對產品：功能太複雜了，得砍。
對同級後端：這個API呼叫的五個函式裡面有一個之前是你實現的吧？能優化一下嗎？
對實習生：我是讓你這麼實現沒錯，但是是基於高內聚低耦合的原理。嗯，這個資料庫是我讓你這麼設計的，是為了符合第二正規化。你聽過反正規化嗎？
對運維：會不會是阿里雲的問題？
線上業務接口出錯：
對測試：我以為測試應該能覆蓋到這個情況的。
對前端：你們接入的時候也沒講清楚你們必須要這個形式/格式/型別的欄位。
對產品：功能太複雜了，我程式碼實現起來很ugly，沒有辦法考慮到所有情況。
對同級後端：這一段我複製的你兩年前的程式碼，誰知道居然有bug沒有被發現。
對運維：你們監控報警太少了/日誌收集太慢了。
任務delay：
對測試：你們報過來的bug太多了，有些小的bug就可以降低一點優先順序過來吧。
對前端：介面都設計好了，開發的時候一直讓改動。
對產品：需求改來改去/功能不合理/時間排的太緊。
對同級後端：老不幹活。
低階錯誤導致業務掛掉：
對運維：你們應該把redis的keys命令禁掉吧？
對測試：這個介面慢成這樣，測試的時候應該當bug提出來啊？
對前端：這個介面慢成這樣，接入的時候應該當bug提出來啊？
對產品：這個需求太奇怪了吧，我只能這麼實現吧？
對同級後端：唉，我程式碼寫成這樣，你code review居然沒看出來？
對自己帶的實習生（在瘋狂查閱資料後）：我讓你遍歷key的時候，意思是用scan。當然，這個主要還是需求不太合理。
沒有理會依賴包的deprecated warning，導致某次部署後掛掉：
對基礎團隊：為什麼一個基礎庫要改的和以前不相容？
對產品：需求太多了，根本沒有時間做技術的升級。
對同級後端：我記得你上個月就說要升級的，啊？我還以為你已經做過了！
不理會文件寫的約束，瘋狂呼叫其他業務導致對方業務掛掉：
對運維：你們的熔斷機制不完善啊？什麼？沒有熔斷？
對產品：討論方案的時候我就講過這個不太合理了。
對對方業務組：你們的提供的介面需要做一下限制，不應該信任呼叫方。
以上。
實際上我想有相當一部分技術人員並不擅長所謂甩鍋，上面的例子統統浮於表面。真正的甩鍋是不形於色，談吐自若，依靠春秋筆法和強大的精神力控制住所有相關利益者的喜怒哀樂，最後於無形之中理所當然的把鍋嫁禍給別人。