作者：手辨 實為吾之愚見,望諸君酌之!聞過則喜，與君共勉 第一節 什麼是max_connect_errors 一開始接觸這個參數的時候，感覺他和max_connections的含義差不多，字面意思簡單明瞭，這個參數的含義是最大連接錯誤數，翻翻mysql的文檔中的解釋是If more than this many successive connection requests from a host are interrupted without a successful […]
作者：手辨 實為吾之愚見,望諸君酌之!聞過則喜，與君共勉 第一章 情景模擬 第一節 工具準備 準備一些需要的工具，方便後面的虛擬場景 1.1.1 模擬密碼本A 密碼本A的字符座標規則：假設一個字符的密文由三部分組成，順序分別是”U+5600的56″+”表格最上方的座標”+”表格最左邊的座標”，舉例”570B”是”國”，”56E7″是”囧”，如下第一個和第二個密碼錶，這些密文是16進制的格式，下同 1.1.2 模擬密碼本B 密碼本B的字符座標規則：假設一個字符的密文由三部分組成，順序分別是”表格左上角的字符串”+”表格最左邊的座標”+”表格最上方的座標”，舉例”87E5″是”囧”，”87F8″是”國”，如下第一個密碼錶，這些密文也是16進制的格式，下同 1.1.3 密文的加密規則 即我們可能還需要對我們拿到的密文進行再一次的加密，比如”囧”的密文是” “56E7”按照開頭假設的密文規則，這是16進制的數，那我們還需要把這個16進制的56E7通過一定的規則，再次加密，針對這兩個密碼本的加密規則假設如下： 密碼本A密文再次加密規則： 16進制密文轉換為10進制後對應的範圍 16進制數轉換為2進制後對應的加密格式
作為數據庫管理員或應用開發者，大家肯定有過SQL優化經歷。數據庫上執行的SQL千差萬別，且伴隨著業務快速迭代、數據分佈特徵變化、熱點變化、數據庫版本升級等持續動態變化，這些都使得SQL優化如同三餐般不可或缺。看似相同的過程，但每次都充滿不一樣的挑戰: 1.如何利用綜合手段實現快速準確的問題定位？例如問題SQL，僅僅從慢日誌中分析是遠遠不夠的。 2.依據數據庫領域專家經驗或工具輔助，如何精準地識別瓶頸點，得出修復／優化建議？ 3.如何全面地評估優化效果、影響面（包括副作用，如對相關SQL，寫操作的影響等），做上線前的安全評估？ 4.對於複雜的部署（如大規模的分庫分表場景），如何選擇灰度策略、變更窗口、安全穩妥地推進線上變更？ 5.如何持續的跟蹤效果，做到萬無一失？ 除此之外，我們還要考慮兩個重要的時間點，如下圖所示，一個簡單的慢SQL趨勢，T1代表我們發現數據庫實例性能異常的時間點，從此刻開始著手慢SQL的優化，T2是優化過程完畢時間點，實例恢復常態。在傳統的優化處理中，這一過程一般完全依賴人力驅動，常常會暴露出兩個方面的嚴重不足： T1過於偏後，即異常發現不及時、響應不及時，即使發現時，問題可能已堆積多時，重病已纏身，已處在故障的邊緣； T2-T1 所代表的處理時間過長，一方面嚴重影響用戶體驗，另一方面大大增加故障風險。 除了上述的兩個問題， 我們還面臨著另外兩個更為嚴峻的挑戰： 如何實現持續優化？在第一時間發現問題及時優化，避免問題積累，保證穩定的同時保持數據庫實例持續處在最佳運行狀態； 如何縮短處理時長，最大限度減少影響，採用綜合治理手段保證數據庫實例穩定性，實現標本兼治？ 傳統方式依賴人力驅動，這兩方面的侷限性會顯得尤為突出，常常處於故障驅動、疲於應對、四處救火的狀態。隨著業務規模發展，實例規模擴大，所有這些問題也隨之被放大，並且大概率會進入即使投入更多人力也沒有辦法解決的惡性循環狀態。 破解之道 自動SQL優化服務是阿里雲數據庫自治服務（DAS）中最為核心服務之一，以自優化的自治能力實現SQL優化的閉環。 如上圖其閉環能力具體體現幾個方面：1）負載（Workload）異常檢測，識別數據庫業務變化，問題SQL的快速識別與定位，如新增慢SQL，性能惡化SQL，不高效SQL等；2）針對問題SQL，自動調用SQL診斷優化服務生成優化建議，如最優索引的創建、SQL語句改寫、引擎推薦等等；3）自動完成優化建議風險評估，根據數據庫實例負載情況、實例畫像自動生成灰度計劃，自動編排優化任務；4）自動選取運維窗口，依據灰度計劃，完成相關線上變更，目前階段主要支持索引的自動上線變更；5）針對上線的變更，啟動多維度的優化效果跟蹤，持續實時全面的性能迴歸風險評估，符合預期，自動計算優化收益，不符預期，自動回滾。 依託該全自動優化閉環，將重人工的被動式優化轉變為以智能化為基礎的主動式持續優化，最終實現SQL優化的無人值守。試想下，它就如同一群數據庫專家7×24小時地守護在你的數據庫旁邊，不知疲倦，時刻保持數據庫系統運行在最佳優化狀態。 當然，為了上述的目標，實現過程中面臨諸多挑戰：
1月中旬，央行徵信中心啟動了二代徵信系統切換上線工作，開始面向社會公眾和金融機構開放二代格式信用報告查詢服務。隨後，深源恆際及時跟進信用報告OCR識別產品的升級工作。目前產品迭代已完成，深源恆際將於本週內上線二代個人信用報告OCR識別服務。 信用報告OCR識別產品主要面向信貸服務機構，提供基於個人信用報告的信息自動化識別與提取服務。基於OCR識別技術結合專項訓練方法構建的信用報告識別專用模型，自動識別、提取個人信用報告上的文本信息，並進行結構化輸出，幫助信貸機構高效提取、採錄用戶信用信息，為信貸決策提供重要參考。 隨著國內市場經濟的深入發展，各種經濟活動的信用關係越來越複雜，建立和完善徵信體系成為信用經濟正常運轉的必要條件。在我國，央行徵信中心作為專門的第三方徵信服務機構，為個人或企業建立“信用檔案”（個人信用報告/企業信用報告），為商業銀行及其他專業化授信機構提供信用信息共享，有效降低交易過程各參與方之間的信息不對稱，以及信息不對稱帶來的交易風險。 其中，被稱為“經濟身份證”的個人信用報告，在個體信貸服務中扮演著重要角色。當信貸機構對外提供授信服務時，基於個人信用報告瞭解用戶既往的信用行為和資信狀況，可以為貸前風險評估和放貸決策提供有力參考，進而有效防範信用風險、保障交易安全。 在實際業務操作層面，信貸機構通常經由用戶授權後從央行徵信中心查詢、下載、打印其個人信用報告，再由人工完成報告信息的逐項填報與錄入，以便風控系統分析、評估潛在的交易風險。然而，一份個人信用報告涵蓋的信息量龐大，尤其徵信系統優化升級後，信息量更加豐富，依託人工錄入耗時且費力，難免影響放貸審批效率，造成意向客戶的流失；或者，為實現快速放款，人工處理信息時刪繁就簡，容易因疏漏導致風險評估失準。 深源恆際信用報告OCR識別服務以自動化方式幫助信貸審核人員快速提取、採錄用戶信用信息，高效完成信用分析與評估。二代徵信系統上線後，深源恆際團隊從模板更新和圖像降噪兩方面著手優化算法模型，完成相應的配套升級。 據悉，二代徵信系統在信息採集、產品加工、技術架構和安全防護四方面進行了優化改進，與一代系統相比，二代徵信系統提供的信用報告優化豐富了基本信息和信貸信息內容，改進了報告生成機制和展示形式，提升了信息更新效率。針對上述變化，深源恆際團隊從兩方面對算法模型進行優化：一是基於二代信用報告格式，強化特徵提取細粒度，更新識別模板，提升模型的識別穩定性；二是提升抗干擾能力，基於直線/表格線識別規則糾正文本畸變，結合啟發式規則實現翻頁文本合併，提高模型的識別準確率。 升級完成後，基於OCR完成單份個人信用報告的提取與錄入用時僅為20s-30s；相較人工作業耗時，信息採錄效率顯著提升。事實上，借力專業化、自動化的信用信息提取服務，信貸服務的交易時間將大幅縮短，有助於信貸服務更加高效、便捷地觸達用戶，加快推進普惠金融發展進程。 點擊進入【復工復產，持續發展】人行徵信報告OCR識別API-查詢徵信報告識別結果【個人徵信明細臨櫃】【二代徵信】
【以下內容為分享實錄，有刪節】 如何解決在家辦公時 “團隊溝通”和“研發流程”問題軟件研發團隊在家辦公時，會遇到的兩個核心問題：團隊溝通和研發流程。因為雲效團隊原本就分佈在多個城市，平時的溝通方式也經常採用“在線會議”，所以“在家辦公”期間大團隊之間的溝通協調受到的衝擊較小。 但是小團隊之間的溝通還是遇到一些問題，平時大家坐在一起，有事情“吼一聲”就解決了，遠程辦公肯定無法做到。經過10多天的磨合，我們逐漸解決了這個問題，提升了溝通效率。下面以雲效團隊為例，簡單介紹下在公司辦公和在家辦公之間的差異。 “晨會”和“週會”上溝通的內容基本沒有變化，主要是會議形式不同。在公司我們都是面對面交流，而在家辦公，會採用電話會議和視頻會議的形式。同時為了提升溝通效率，我們在會前需要同步個人工作項、明確會議主題。在家辦公期間，除“週報”外，我們增加了“日報”，主要是為了在每天下班前披露個人工作進度和可能存在的風險。 在“研發流程”方面，如果你的團隊不是採用“在線化”“白屏化”這種標準流程的話會遇到比較大的挑戰。一旦在發佈過程中遇到問題或故障，在家辦公時，不像在公司可以很方便的找到人，這會造成問題的放大。阿里巴巴在研發流程方面一直是做得比較好的，我們主要通過“Aone”（雲效是阿里巴巴自研的DevOps平臺，內部名稱為Aone）這個研發工具來承載整個研發流程的，包含了開發、構建、部署和安全生產等流程。 在家辦公期間，我們主要是通過“敏捷研發”和“持續交付”來解決的“團隊溝通”和“研發流程”這兩個問題，接下來，會詳細介紹一下我們是怎麼做的。 以迭代為核心的敏捷研發“敏捷研發”其實是一套非常成熟的方法論，但是所謂“一千個人心中有一千個哈姆雷特”，每個研發團隊都應該“理論結合實際”磨合出一套符合自己團隊的方法和機制。通過雲效團隊的實踐，我們認為：敏捷研發應該以迭代為核心，其中的關鍵是要進行“異步溝通”。 為什麼這麼說呢？因為“迭代”是長期或者最終目標的拆解，當大的目標變成小的目標之後，我們的團隊會對這些“小目標”更有感知。當以迭代為中心後，我們會將這些“小目標”再拆解成“工作項”或者“看板”上的“卡片”，並落實到每個人身上，這也就形成了“異步溝通”的基礎。 “異步溝通”相對於“同步溝通”，優勢在哪裡呢？首先，能夠積累“上下文”。異步溝通時，我們溝通的內容都會記錄到工作項上；而同步溝通，更多的是以口頭傳達。其次，這也讓每個人能明確自己的目標，讓大家保持專注，減少打擾，從而提高效率。 雲效團隊會將“工作項”分成三類：日常缺陷、項目需求、產品需求。“日常缺陷”很好理解，主要是對已上線產品的維護性工作，缺陷來自用戶反饋或自測。“項目需求”一般比較複雜，交付週期較長，有明確的交付時間，來自企業客戶或者企業自身內部需求。“產品需求”更多是面向大眾，需要持續演進。接下來，我們介紹針對這三種不同的工作項，雲效團隊是如何進行實踐的。 如何處理“日常缺陷”。首先，雲效團隊會將“日常缺陷”分成四個類別：緊急缺陷立刻修復；一週內修復缺陷；兩週內修復缺陷；不修復缺陷。為什麼這麼做呢？因為“缺陷”相比於“需求”來說，是更加“明確”的，變化比較少，大家在認領的時候，基本可以確認什麼時間可以完成。 第二，缺陷不會佔用“故事點”。背後的含義是，不會把修復缺陷的時間計算到你正常的工作時間裡，要求大家利用空閒時間去完成。這其實建立了一套正向激勵的機制，因為“任務”和“需求”的工作項會帶來一定的缺陷，當你的工作項完成的質量越高的時候，相應的，你的缺陷就會越少。反之亦然。這個機制就鼓勵大家儘可能的把自己的工作項做到最好。 第三，晨會不過缺陷，而是在週會核查上週缺陷進度，確認新增缺陷分類和指派人。這套機制非常簡單，而簡單的機制其實更利於執行。雲效在踐行這套機制處理日常缺陷後，我們自己的產品質量也得到了很大的提升和保障。 如何處理“項目需求”。 項目需求一般有確定的完成時間點，且需求明確。我們會根據確定完成時間點，倒推關鍵時間，明確里程碑。這樣做主要是為了更好的把控風險。需要注意的是，里程碑的內容一定是可量化的、可觀測的。然後我們會根據里程碑形成迭代，每個迭代開始前做需求澄清和故事點評估。這樣做跟敏捷研發方法論實際上是一致的。需要注意的是，在團隊培養方面，每個人的技能應該是儘可能均衡的。這樣我們從迭代拆解出來的“工作項”或“卡片”， 任意一個開發者都可以做，而不會和特定的人綁定。這樣就不會因為某一位開發者技能的不足而形成瓶頸。 如何處理“產品需求”。 產品需求和項目需求工作項上的處理比較類似，都需要做需求澄清、故事點評估，然後在“站會”上進行“卡片”認領，風險預警等工作。主要的差異點是產品需求的迭代週期相對固定，這有益於保持產品穩健的延續性。如果迭代週期有時長有時短，這意味著在同樣的研發週期中開發者處理的“卡片”數量是有稀疏的，這就可能造成交付質量的差異。另外一個不同點是，產品需求的迭代目標一般是根據用戶、市場和數據的反饋而產生的，存在一定的不確定性。這就要做一些“需求澄清”，在需求評審上也會更細緻一些。 雲效在踐行敏捷研發的過程中取得了很好的效果，團隊成員也比較有成就感。我們的一個心得體會就是：找到團隊的節奏非常重要。希望大家也能夠在敏捷研發的實踐中，找到自己團隊的節奏，探索出一套適合自己團隊的敏捷研發機制。
在線編程介紹 阿里雲開發者社區在線編程產品，針對廣大開發者學習、實踐、面試、應聘、考試認證等打造的免費在線刷題神器。題庫來自筆試模擬題、算法大賽模擬題等，界面整潔明瞭，操作簡單，為用戶營造專心答題的學習環境。點擊鏈接開始體驗：https://developer.aliyun.com/coding 本文為大家介紹其中的 第97題：破譯密碼 的題目解析，具體如下： 題目描述 題目等級：中等知識點：尺取法 查看題目：破譯密碼 給你一個長度為n的序列，元素標號1-n。問能夠找到多少對不同的（L,R）（1 <= L <= R），使得在子序列[L,R]內存在出現頻率不低於K的元素？ 輸入序列大小n（1 <= n <= 10^4）、出現頻率k（1 <= k
“打不倒的創業精神，我們為您護航” 本期公益雲路演由阿里雲創新中心&良倉加速器&起行資本聯合出品，將傳統的線下路演移植到線上，在線進行項目路演、點評互動等環節。全國甄選核心賽道優秀企業，與知名投資機構、優秀創業項目一起，復甦新生，銳意前行。 起行資本介紹： 起行資本成立於2018年冬，先後在杭州、上海、廣州、香港和北京設立辦公室，旗下管理著人民幣和美元雙幣基金，管理資產總額約20億人民幣。 基金專注於大消費、創新科技與應用領域的A&B輪的投資機會，走精品投資路線，覆蓋新零售、人群分級消費機會、行業SaaS、人工智能、網絡安全等行業。創始團隊在全球歷史投資總計超過12億美金，逾50家科技互聯網企業，企業累計估值超過180億美金。 直播內容： ◆4大優質項目在線路演◆知名投資機構專場參與
在線編程介紹 阿里雲開發者社區在線編程產品，針對廣大開發者學習、實踐、面試、應聘、考試認證等打造的免費在線刷題神器。題庫來自筆試模擬題、算法大賽模擬題等，界面整潔明瞭，操作簡單，為用戶營造專心答題的學習環境。點擊鏈接開始體驗：https://developer.aliyun.com/coding 本文為大家介紹其中的 第135題：Password 的題目解析，具體如下： 題目描述 題目等級：容易知識點：字符串、枚舉 查看題目：Password Tom在期末考完試以後學習了Python語言，他發現Python語言確實是簡潔又強大，在他學完字符串以後，他寫了一個隨機生成密碼的python文件。 原理是這樣的，輸入一個字符串s，然後系統會隨機將這個s重新任意排序，然後又生成兩個字符串s1和s2，並拼接起來最終生成隨機密碼str = s1 + s + s2。 現在Tom有一個問題要問你，每次給你兩個字符串，一個是s(表示輸入的字符串)，一個是str(表示產生的隨機字符串)，問這兩個字符串是否符合上述要求的原理？如果符合輸出YES，否則輸出NO。1<=s,str<=100 輸入兩個字符串，一個是s，表示輸入的字符串，一個是str，表示產生的隨機字符串（1<=s,str<=100） 輸出內容為一行字符串，如果符合題意中的原理輸出”YES”，否則輸出”NO”。 示例1輸入：”abc””xxxcabyyy”輸出：”YES”
行業: 通用行業. 應用場景: 全託管數據庫無法滿足某些場景的需求: 1、客戶自定義需求, PG 數據庫引擎具備插件擴展能力, 但是RDS內置的插件為常用插件, 無法覆蓋某些客戶的需求,例如: CITUS 分佈式數據庫插件(許可問題), timescaledb 時序數據庫插件(許可問題), trodb mongo兼容版插件(許可問題), zombodb es索引插件(許可問題), madlib 機器學習插件(權限問題),
智能建築依賴於一箇中央建築管理系統（BMS），它可以協調從氣溫到安全狀況的所有方面。一個功能齊全的BMS在業務開始時打開門鎖，打開暖通空調，管理電梯使用，以優化建築內的交通流。在壞人手中，BMS可以用於從騷擾到大規模犯罪活動的所有活動。 五大目標 BMS是否位於結構的中心，安全位置的異地或雲中都沒有關係。如果沒有正確的安全管理協議，BMS就是物業經理最擔心的問題，並且經常遭受未經授權的入侵。去年，英特爾對500多名建築經理進行了調查，以確定哪些BMS組件構成了最大的網絡安全風險。最受關注的五個系統是： 安全系統 IoT/M2M傳感器或解決方案 人員/資產管理 能源管理 火災探測和報警 最終，這些系統中的任何一個都可以連接到更廣泛、更具包容性的設備，連接到敏感數據存儲、服務器，甚至員工和客戶信息。作為BMS的一部分，通過一系列物聯網平臺進行連接，每個平臺都會受到惡意軟件攻擊、身份和數據盜竊、機器人和黑客等各種威脅。保護員工、公司數據和客戶的安全正成為物業經理的一個高度優先事項。 保持領先 智能建築最重要的新技術進步之一是開發和實現網絡恢復功能。它要求物業經理與物聯網專業的安全合作伙伴密切合作，後者可以識別建築智能管理平臺中的漏洞和風險。即使是最合格的物業經理也可能不具備識別編程、連接和其他網絡威脅風險的專業知識和培訓。 一家可靠的IoT安全公司可以瞭解今天的威脅和技術攻擊，並且可以認識到如何像堡壘一樣保護BMS。 IBM道德黑客（ethical hackers）進行了一次網絡攻擊，以確定BMS的風險。該小組能夠通過使用三個IP地址訪問一個BMS。一旦他們獲得了訪問權限，他們發現同一個密碼被用於不同級別的安全訪問，使得整個建築都容易受到他們的入侵。演習結束時，IBM指出，一項調查發現，只有不到三分之一的建築經理採取了措施來保護他們的BMS。 未來五年，智能建築投資有望翻兩番，這意味著黑客可以利用更脆弱的技術。在BMS的世界裡，競爭不是在下一個街區或街對面。它可能在地球另一邊的一個倉庫裡。保護財產和人員意味著找到一家物聯網安全公司並與之合作，以期在威脅到來之前發現並阻止它。 原文鏈接