感謝 웷篘梅、宙斯 提供珍貴的思路：）
每天收集點思路，留給自己以後用。
1. 敏感檔案資訊洩露
情景一【壓縮包洩露】
許多站長在部署**時，會將將所有的原始碼壓縮成乙個包（比如1.zip等），然後通過ftp等方法上傳到伺服器上，然後再解壓縮，而許多粗心的站長則會忘記把這個壓縮包刪除。一旦這些檔案被黑客暴力遍歷到這個壓縮包，那麼整個**就會被輕易拿下。
情景二 【備份檔案洩露】：
站長在給**更新頁面的時候，直接把原來的檔案重名一下，這也很容易留下大的隱患。比如，更新index.php頁面內容時，將原來的inpdex.php重名為index.php2，index.php.bak等，黑客一旦得到這些檔案原始碼，就很容易收集伺服器上的相關資訊，重則直接導致**淪陷。
情景三 【測試檔案洩露】
在**開發時，作為開發者肯定需要測試，有時候為檢測某個功能點時，我們傾向於寫乙個簡單的測試指令碼，比如，我們為測試資料庫相關介面而寫了乙個test_db.php，裡面全部是用測試的詳細資訊。一旦這些涉及到敏感資訊的測試檔案被黑客拿到的話，後果將不堪設想。
情景四 【phpinfo】
百分之九十九的站長在部署的**的第一件事就是寫乙個phpinfo.php，檢視配置資訊是否正確。由於這個檔案包含了伺服器web配置資訊，黑客會根據這些配置資訊來選擇下一步的攻擊入口。
情景五 【敏感目錄洩露】
很多**的管理登陸入口，就是簡單的預設通用路徑（或這容易讓入侵者通過暴力方式或者社工破解管理密碼，進而進入**後台。還有乙個例子就是dede cms，現在許多**都存在search.php漏洞，通過此漏洞可以直接爆管理員密碼，倘若管理後台路徑沒有修改，直接直接用預設的那麼黑客就可以輕而易舉地破門而入。
情景六 【搜尋引擎獲取敏感資訊】
情景七 【web框架資訊】
**配置跳轉，錯誤等資訊的原則應該是越少越安全，盡量隱藏web框架資訊（系統-前段-中介軟體-後端等相關資訊），甚至可以加點混淆的方法，比如把iis混淆成apache，nginx混淆成squid等。舉個例子，如果某**使用的struts版本存在漏洞
，那麼一旦被入侵者獲知就很容易成為其攻擊入口。
2.
jekkay hu，胡楊
2013/11/21
能解決 80 故障的排查思路 ，建議收藏。。
業務人員反映呼叫中心系統執行緩慢，部份 在自助語言環節系統處理超時，話務轉人工座席，人工座席出現爆線情況。運維人員開始忙活了，查資源使用情況 查服務是否正常 查日誌是否報錯 查交易量還有沒有 時間不知不覺的在敲鍵盤 敲鍵盤 敲鍵盤中過去，但是原因還未定位。經理過來了解情況 系統恢復了嗎？故障影響是什...
redis的key設定每天凌晨過期的思路
設定key的值的時候，計算下當前時間到第二天凌晨的時間差，設定key的過期時間。利用定時任務，每天凌晨將需要過期的key刪除。按天為維度，限制使用者對資源的訪問次數。按天為維度，生成遞增序列號。按使用者id和天為維度生成遞增的單號 return private string createno int...
產品的一點思路
一 產品描述 1.是什麼樣的產品？包括產品規則 內容 功能 產品特色等 2.和市場上的產品有什麼不同？3.產品生命週期如何延續？二 市場分析 1.分析市場上現有同型別產品的優劣勢 2.目標消費市場人群分析，人群細分 3.潛在消費使用者分析 4.使用者操作習慣分析，使用者體驗等 三 產品定位 四 市場...