พวกเขาเป็นอย่างไร

การแนะนำ
วิธีที่พวกเขาเป็น วิธีที่พวกเขาเป็นที่เก็บความรู้ที่ได้รับการดูแลจากแนวทางปฏิบัติที่ดีที่สุดของไซต์วิศวกรรมความน่าเชื่อถือ (SRE) เครื่องมือเทคนิคเทคนิคและวัฒนธรรมที่นำมาใช้โดยเทคโนโลยีชั้นนำหรือองค์กรที่มีความเชี่ยวชาญด้านเทคโนโลยี
หลายองค์กรมักแบ่งปันข้อมูลเชิงลึกและความเชี่ยวชาญของพวกเขาครอบคลุมแนวปฏิบัติที่ดีที่สุดเครื่องมือและเทคนิคที่กำหนดวัฒนธรรมทางวิศวกรรมของพวกเขา พวกเขาทำสิ่งนี้ผ่านแพลตฟอร์มสาธารณะต่าง ๆ เช่นบล็อกวิศวกรรมการประชุมและการพบปะ ที่เก็บนี้รวบรวมและนำเสนอเนื้อหาที่รวบรวมจากแหล่งเหล่านี้
หัวข้อ
- วิศวกรรมความน่าเชื่อถือของไซต์
- การจ้างและการสร้างทีม SRE
- วัฒนธรรม SRE
- Devops
- การตรวจสอบและการสังเกต
- การแจ้งเตือน
- การตอบสนองของเหตุการณ์และการชันสูตรศพ
- สาย
- การทดสอบในการผลิต
- วิศวกรรมความโกลาหล
- ระบบอัตโนมัติ
- ผลงาน
- วิศวกรรมแพลตฟอร์ม
องค์กร
ผู้ประสบความสำเร็จ
โพสต์บล็อก
- เข้าสู่เครื่องมือ Gitops 'à la carte' อาคาร
- การปรับขนาดการผลิตทั่วโลก-การปรับแต่งการบริการ (ตอนที่ 1)
- การปรับขนาดการผลิตทั่วโลก - การแก้ปัญหาการสังเกตสำหรับนักพัฒนา (ตอนที่ 2)
- การทดสอบโหลด Kubernetes: การสร้างเฟรมเวิร์ก (ตอนที่ 1)
- การทดสอบโหลด Kubernetes: การแก้ไขปัญหาคอขวดและปรับปรุงประสิทธิภาพ (ตอนที่ 2)
Airbnb
โพสต์บล็อก
- การจัดการเหตุการณ์อัตโนมัติผ่าน Slack
- การตรวจจับช่องโหว่ด้วยช่องโหว่
- การแจ้งเตือนเฟรมเวิร์กที่ airbnb
- เมื่อเมฆมืดลง - การหยุดทำงานของอเมซอนส่งผลต่อ Airbnb อย่างไร
- แพลตฟอร์มระบบอัตโนมัติอัจฉริยะ: เพิ่มขีดความสามารถ AI การสนทนาและอื่น ๆ ที่ Airbnb
- การจัดการความลับการผลิตที่ Airbnb
- การป้องกันข้อมูลอัตโนมัติในระดับส่วนที่ 1
- การป้องกันข้อมูลอัตโนมัติในระดับส่วนที่ 2
- การป้องกันข้อมูลอัตโนมัติในระดับส่วนที่ 3
- การปรับขนาดคลัสเตอร์ Kubernetes แบบไดนามิกที่ airbnb
อัลโกเลีย
โพสต์บล็อก
- 30 พฤษภาคมเหตุการณ์ SSL
- การเดินทางสู่ SRE
- CI/CDAY 2024: อะไรทำให้แพลตฟอร์ม CI/CD ที่ดีคืออะไร?
Alibaba Cloud
โพสต์บล็อก
- เหตุใด บริษัท อินเทอร์เน็ตชั้นนำจึงเลือก SRE มากกว่า O&M แบบดั้งเดิม
- สถาปัตยกรรมและการปฏิบัติของแพลตฟอร์มแบบเรียลไทม์ของ Bilibili
อาสนะ
โพสต์บล็อก
- Asana ใช้ Asana อย่างไร: การตอบสนองของเหตุการณ์ความปลอดภัย
- Asana จัดส่งเว็บแอปพลิเคชันที่มีเสถียรภาพอย่างไร
- การวิเคราะห์การหยุดทำงานล่าสุดและสิ่งที่เรากำลังทำเพื่อป้องกันเหตุการณ์ในอนาคต
- สภาพแวดล้อมของนักพัฒนา: บรรลุความน่าเชื่อถือด้วยการรีเซ็ตอย่างรวดเร็ว
- สามกลยุทธ์การรักษาความปลอดภัยสำหรับผู้นำไอทีทุกคนที่จะพิจารณาฤดูใบไม้ร่วงนี้
asos
โพสต์บล็อก
- เล่นเกมที่ไร้โทษ
- วันหนึ่งในชีวิตของ… Cat S (หัวหน้าวิศวกรรมความน่าเชื่อถือ)
- AKS Performance Journey: ตอนที่ 1 - ปรับขนาดทุกอย่างขึ้น
- AKS Performance Journey: ตอนที่ 2 - เครือข่ายออกมา
- Cyber Security @ asos.com
- การดำเนินงานด้านความปลอดภัย 24x7
- ทักษะที่เรามองหาในการตอบสนองเหตุการณ์ความปลอดภัยในโลกไซเบอร์
ชาวแอตลาสเซีย
โพสต์บล็อก
- แนวทางปฏิบัติที่ดีที่สุดสำหรับการจัดการการเปลี่ยนแปลงในยุคของ DevOps
- การทดสอบอัตโนมัติ: 5 บทเรียนจากทีม Kubernetes ของ Atlassian ในการทดสอบโครงสร้างพื้นฐานเป็นรหัส
- วิธีส่งออกเหตุการณ์ Kubernetes เพื่อการสังเกตและการแจ้งเตือน
- เทมเพลตการชันสูตรศพ
แบ็คมาร์เก็ต
โพสต์บล็อก
- Back Market Sres เตรียมไว้สำหรับ Black Friday อย่างไร
Baidu
วิดีโอ
- การตรวจจับความผิดปกติบนสัญญาณทองคำ
- NetRadar: การตรวจสอบเครือข่าย DataCenter
- ปล่อยให้ความวุ่นวายเริ่มต้น - วิศวกรรมความโกลาหลที่ตรงกับความปลอดภัยทางไซเบอร์
basecamp
โพสต์บล็อก
- ภายในรหัสสีแดง: Network Edition
- การหยุดทำงานของ Basecamp สามครั้ง หนึ่งสัปดาห์ เกิดอะไรขึ้น
- รายงานการค้นหา Basecamp 2 และ Basecamp 3
- ลดการเพิ่มเหตุการณ์ที่ Basecamp
หนังสือ
บลูมเบิร์ก
วิดีโอ
- การวางแผนกำลังการผลิตและการเพิ่มประสิทธิภาพด้วยการสุ่มตัวอย่างอ้างอิงหน้า
- ทำไม SRE ไม่สามารถที่จะไม่ทำวิศวกรรมความโกลาหล
- ติดตามระบบกระจายแบบเรียลไทม์
- The Bloomberg Story: การสร้างทีม SRE ในองค์กรที่ "ไม่สามารถวัดได้"
- ทัศนวิสัยในคนตัดไม้ (และบริการระดับต่ำอื่น ๆ ) - ดูต้นไม้จากป่า
booking.com
โพสต์บล็อก
- ความน่าเชื่อถือและทีมผลิตภัณฑ์ทำงานร่วมกันได้อย่างไรที่ booking.com
- เหตุการณ์การแก้ไขและวันต่อมา
- การแก้ไขปัญหา: การเดินทางสู่สิ่งที่ไม่รู้จัก
วิดีโอ
- SLOs สำหรับบริการที่เน้นข้อมูล
- ประโยชน์ของการใช้ถนนที่มีการเดินทางน้อยลงด้วยโครงสร้างพื้นฐานของภาชนะบรรจุ
เมืองหลวง
โพสต์บล็อก
- ทำการตรวจสอบแอปพลิเคชันโดยอัตโนมัติด้วย Slack
- สร้างโครงสร้างพื้นฐาน AWS อัตโนมัติด้วย Boto 3: AWS Health Check
- สถาปัตยกรรมฐานข้อมูลที่ใช้งานร่วมกันแบบแอคทีฟ
- 3 R's of SRES: ความยืดหยุ่นการกู้คืนและความน่าเชื่อถือ
- 5 ขั้นตอนในการเตรียมแอปของคุณให้พร้อม
- 4 สถานการณ์โลกแห่งความจริงที่อ่านเช่นการทดลองทางวิศวกรรม Chaos
- โอบกอดความโกลาหล…วิศวกรรม
- 3 บทเรียนที่เรียนรู้จากการนำวิศวกรรม Chaos ที่ Enterprise มาใช้
- การดำน้ำลึกลงไปในการปรับใช้สีน้ำเงิน/สีเขียวที่ไร้รอยต่อโดยใช้ AWS codeDeploy
- ตู้คอนเทนเนอร์ที่ปลอดภัยต้องใช้แอปพลิเคชันที่ปลอดภัย
- 4 ขั้นตอนสำหรับการจับคู่คลาวด์และ DevOps เพื่อปรับปรุงความยืดหยุ่น
- แอพพลิเคชั่นพร้อมคอนเทนเนอร์พร้อมแอพสิบสองปัจจัยและสถาปัตยกรรม Microservices
- การปรับใช้ด้วยความมั่นใจ - ลดความเสี่ยงเพิ่มความยืดหยุ่นสูงสุดด้วยการปรับใช้ Canary บน AWS
- สถาปัตยกรรมเพื่อความยืดหยุ่น
- ความโกลาหลอย่างต่อเนื่อง - แนะนำวิศวกรรมความโกลาหลในการฝึกฝน DevOps
- Mon-Ifesto ตอนที่ 1: ตัวชี้วัด
เหตุการณ์สำคัญและรายงานการวิเคราะห์
- ข้อมูลเกี่ยวกับเหตุการณ์ไซเบอร์ Capital One
- กรณีศึกษาการละเมิดข้อมูล Capital One
วิดีโอ
- ธนาคารเกี่ยวกับการจัดส่งอย่างต่อเนื่อง - Capital One
- ความโกลาหลอย่างต่อเนื่องใน DevOps - Capital One
- DevOps at Capital One: มุ่งเน้นไปที่ท่อและการวัด
- การจัดการสุขภาพการปฏิบัติงานของบัญชีคลาวด์โดยอัตโนมัติ
เหรียญเหรียญ
โพสต์บล็อก
- เปิดการปรับใช้ที่ปลอดภัยของ Coinbase
คนขี้ขลาด
โพสต์บล็อก
- ความน่าเชื่อถือของไซต์ที่ Dazn
เดซิเบล
โพสต์บล็อก
- นำเสนอในการประชุม SRE ของ Ithome: การเดินทางการเปลี่ยนแปลง DBS SRE ของเราจนถึงตอนนี้
- debunking ตำนานวิศวกรรมความน่าเชื่อถือของไซต์ที่ได้รับความนิยมมากที่สุด
- วิธีใช้ SRE เพื่อปลูกฝังวัฒนธรรมที่ไม่มีที่ติในที่ทำงาน
- วิศวกรรมความน่าเชื่อถือของไซต์ที่ DBS Bank
- การจัดการการกำหนดค่าอัตโนมัติในระดับ
- DBS กำจัดตำนานของความโกลาหลวิศวกรรมได้อย่างไร
- เป็นสองเท่างานหนักและปัญหา
วิดีโอ
- SRECON Conversations Asia/Pacific กับ Koon Seng Lim, DBS
DEEPSORCE
โพสต์บล็อก
- Redis Diskless Replication: อะไร, ทำไมและคำเตือน
- วิธีการตั้งค่า Vault กับ Kubernetes
- ทำลายการปรับใช้การหยุดทำงานเป็นศูนย์ใน Kubernetes
Dream11
โพสต์บล็อก
- การปรับใช้ตามมาตราส่วน: เรื่องราวเบื้องหลังแพลตฟอร์มการปรับใช้สีน้ำเงินสีเขียวของ Dream11 ในบ้าน 'OneClick'
- เพิ่มความปลอดภัยและความไว้วางใจด้วย AWS WAFV2
- บทเรียนที่เรียนรู้จากการรัน GraphQL ในระดับ
- ทำลายวงจรบันทึก Kong?
- การค้นหาคำสั่งซื้อในความโกลาหล: วิธีการทดสอบประสิทธิภาพโดยอัตโนมัติด้วยแรงบิด
- การรักษารุ่นไฮเปอร์-โซนิคที่ Dream11
- เพื่อปรับขนาดหรือขยาย? นี่คือวิธีที่เราขยายที่ Dream11
- การสร้างการวิเคราะห์แบบเรียลไทม์ที่ปรับขนาดได้การแจ้งเตือนและสถาปัตยกรรมการตรวจจับความผิดปกติที่ Dream11
กล่องดร็อปบ็อกซ์
โพสต์บล็อก
- Dropbox Engineering Career Framework - วิศวกรความน่าเชื่อถือ (SRE)
- ATLAS: การเดินทางของเราจาก Python Monolith ไปยังแพลตฟอร์มที่มีการจัดการ
- การตรวจสอบแอปพลิเคชันเซิร์ฟเวอร์ด้วยกระแสน้ำวน
- Athena: ระบบการจัดการสุขภาพแบบอัตโนมัติของเรา
- สนใจที่จะเป็นวิศวกรความน่าเชื่อถือของไซต์หรือไม่?
วิดีโอ
- ความท้าทายในการค้นพบบริการในระดับ
อีเบย์
โพสต์บล็อก
- ความยืดหยุ่นและการกู้คืนภัยพิบัติด้วย Kafka
- กรณีศึกษา SRE: triaging jvm ที่ไม่ใช่กองออกจากปัญหาหน่วยความจำ
- กรณีศึกษา SRE: ความไม่สมดุลของการจราจรลึกลับ
- การหยุดทำงานเป็นศูนย์การปรับใช้ทันทีและการย้อนกลับ
- แพลตฟอร์มการแจ้งเตือนของ eBay ใช้การฉีดข้อผิดพลาดในรูปแบบใหม่อย่างไร
วิดีโอ
เกมมหากาพย์
วิดีโอ
- AWS Re: Invention 2018: Epic Games ใช้ AWS เพื่อส่งผู้เล่น Fortnite ให้กับผู้เล่น 200 ล้านคน
Etsy
โพสต์บล็อก
- การปรับปรุงประสบการณ์การปรับใช้ของแอปพลิเคชันอายุสิบปี
- Etsy เตรียมพร้อมสำหรับปริมาณการใช้งานวันหยุดในประวัติศาสตร์ในปี 2020 อย่างไร
- สมองของคุณมีความคืบหน้า
- คู่มืออำนวยความสะดวกในการซักถามของ Etsy สำหรับการชันสูตรศพไร้ที่ติ
- Opsweekly: การวัดประสบการณ์การโทรด้วยการจำแนกการแจ้งเตือน
- การหยุดชะงักของเว็บไซต์
- การชันสูตรศพไม่มีที่ติและวัฒนธรรมที่ยุติธรรม
- วัดทุกอย่างวัดทุกอย่าง
วิดีโอ
- ความเร็ว 09: John Allspaw และ Paul Hammond, "10+ ปรับใช้ PE
- การโยกย้ายเสาหินไปยังคลาวด์
ค่าตอบแทน
โพสต์บล็อก
- มาตรฐานประสิทธิภาพอัตโนมัติ
- นโยบายงบประมาณข้อผิดพลาด - ส่วนที่ 1 - การยอมรับที่ Expedia Group
- นโยบายงบประมาณข้อผิดพลาด - ส่วนที่ 2 - แนวทางปฏิบัติที่ Expedia Group
- การใช้การฉีดข้อผิดพลาดเพื่อปรับปรุงความน่าเชื่อถือของแพลตฟอร์มรันไทม์ใหม่ของเรา
- การเรียนรู้จากเหตุการณ์ที่ Expedia Group
- การปรับปรุงประสบการณ์การโหลดโฮมเพจ VRBO
- การแก้ไขปัญหา 502 ข้อผิดพลาด: รายการตรวจสอบ ECS
- เริ่มต้นใช้งาน ElasticSearch
- ทั้งหมดเกี่ยวกับปัญหา istio-proxy 5xx
- Autoscaling ใน Kubernetes: ทำไม Autoscaler POD แนวนอนไม่ทำงานสำหรับฉัน?
- วิธีการให้การปรับใช้ Kubernetes ของคุณสมดุลในหลายโซน
- ตัวชี้วัดเวลาแฝงแบบ dropwizard ของคุณทำให้คุณเข้าใจผิดหรือไม่?
- ค่าใช้จ่ายความน่าเชื่อถือ 100%
- การสร้างแดชบอร์ดการตรวจสอบ
- ใช้ Bash สำหรับ DevOps
อย่างเกียจคร้าน
วิดีโอ
- การจัดการ SRE & ผลิตภัณฑ์: วิธีการยกระดับทีมของคุณ (และอาชีพ!) โดยคิดเหมือนผู้จัดการผลิตภัณฑ์
- ความยืดหยุ่นทางวิศวกรรมทางวิศวกรรมตำนาน
G-Research
โพสต์บล็อก
- การเดินทาง SRE ของเราที่ G-Research
- การเดินทางของ SRE ยังคงดำเนินต่อไป
- OpentsDB Meta Cache-แลกเปลี่ยนเพื่อประสิทธิภาพ
การเดินเล่น
โพสต์บล็อก
- วิธีที่เราจัดการกับเหตุการณ์ที่ Getaround
- วิวัฒนาการของกระบวนการจัดส่งอย่างต่อเนื่องของเรา
คนอื่น ๆ
โพสต์บล็อก
- วิธีที่เราปรับปรุงความพร้อมใช้งานผ่านการทำให้ง่ายขึ้นซ้ำ ๆ
- วิธีที่เราปรับปรุงการประมวลผลแบบพุชบน gitHub
- วิธีที่ GitHub ใช้คิวการผสานเพื่อจัดส่งการเปลี่ยนแปลงหลายร้อยครั้งทุกวัน
- การแก้ไขช่องโหว่ด้านความปลอดภัยด้วย AI
- โปรแกรมพื้นฐานทางวิศวกรรมของ GitHub: วิธีที่เราส่งมอบเกี่ยวกับความพร้อมใช้งานความปลอดภัยและการเข้าถึงได้อย่างไร
- วิธีที่ GitHub ใช้การกระทำของ GitHub และการกระทำที่มีขนาดใหญ่ขึ้นเพื่อสร้างและทดสอบ github.com
- การเดินทางของ GitHub Security Lab เพื่อเปิดเผย 500 CVEs ในโครงการโอเพนซอร์ส
- CodeQl Team ใช้ AI เพื่อตรวจจับความเสี่ยงในการใช้พลังงานในรหัส
- แก้ไขปัญหาความพร้อมใช้งานล่าสุดของ GitHub
- การสร้างการกำกับดูแลทั่วทั้งองค์กรและการใช้ซ้ำสำหรับ CI/CD และระบบอัตโนมัติด้วยการกระทำของ GitHub
- การเปิดใช้งานการปรับใช้สาขาผ่านปัญหาที่มีการกระทำของ GitHub
- การใช้ Chatops เพื่อช่วยการกระทำของวิศวกรทางโทรศัพท์
- การแบ่งฐานข้อมูลเชิงสัมพันธ์ของ GitHub เพื่อจัดการกับมาตราส่วน
- เพิ่มความสุขของนักพัฒนาด้วยการสแกนรหัส GitHub
- ทำไม (และอย่างไร) GitHub ใช้ opentelemetry
- การปรับปรุงประสิทธิภาพ monorepo ขนาดใหญ่บน GitHub
- ความน่าเชื่อถือในการปรับใช้ที่ GitHub
- ปรับปรุงวิธีการปรับใช้ gitHub
- การสร้างวัฒนธรรมการโทรที่ GitHub
- ลดการสร้างขุยโดย 18x
- บทบาทการพัฒนาของการดำเนินงานใน DevOps
- เริ่มต้นใช้งานระบบอัตโนมัติ DevOps
- MySQL มีความพร้อมสูงที่ GitHub
เหตุการณ์สำคัญและรายงานการวิเคราะห์
- รายงานความพร้อมใช้งานของ GitHub: สิงหาคม 2567
- รายงานความพร้อมใช้งานของ GitHub: กรกฎาคม 2567
- รายงานความพร้อมใช้งานของ GitHub: มิถุนายน 2567
- รายงานความพร้อมใช้งานของ GitHub: พฤษภาคม 2567
- รายงานความพร้อมใช้งานของ GitHub: เมษายน 2567
- รายงานความพร้อมใช้งานของ GitHub: มีนาคม 2567
- รายงานความพร้อมใช้งานของ GitHub: กุมภาพันธ์ 2567
- รายงานความพร้อมใช้งานของ GitHub: มกราคม 2567
- รายงานความพร้อมใช้งานของ GitHub: ธันวาคม 2566
- รายงานความพร้อมใช้งานของ GitHub: พฤศจิกายน 2566
- รายงานความพร้อมใช้งานของ GitHub: ตุลาคม 2566
- รายงานความพร้อมใช้งานของ GitHub: กันยายน 2566
- รายงานความพร้อมใช้งานของ GitHub: สิงหาคม 2566
- รายงานความพร้อมใช้งานของ GitHub: กรกฎาคม 2023
- รายงานความพร้อมใช้งานของ GitHub: มิถุนายน 2566
- รายงานความพร้อมใช้งานของ GitHub: พฤษภาคม 2566
- รายงานความพร้อมใช้งานของ GitHub: เมษายน 2566
- รายงานความพร้อมใช้งานของ GitHub: มีนาคม 2566
- รายงานความพร้อมใช้งานของ GitHub: กุมภาพันธ์ 2566
- รายงานความพร้อมใช้งานของ GitHub: มกราคม 2566
- รายงานความพร้อมใช้งานของ GitHub: ธันวาคม 2565
- รายงานความพร้อมใช้งานของ GitHub: พฤศจิกายน 2565
- รายงานความพร้อมใช้งานของ GitHub: ตุลาคม 2565
- รายงานความพร้อมใช้งานของ GitHub: กันยายน 2565
- รายงานความพร้อมใช้งานของ GitHub: สิงหาคม 2565
- รายงานความพร้อมใช้งานของ GitHub: กรกฎาคม 2565
- รายงานความพร้อมใช้งานของ GitHub: มิถุนายน 2565
- รายงานความพร้อมใช้งานของ GitHub: พฤษภาคม 2565
- รายงานความพร้อมใช้งานของ GitHub: เมษายน 2565
- รายงานความพร้อมใช้งานของ GitHub: มีนาคม 2565
- รายงานความพร้อมใช้งานของ GitHub: กุมภาพันธ์ 2565
- รายงานความพร้อมใช้งานของ GitHub: มกราคม 2565
- รายงานความพร้อมใช้งานของ GitHub: ธันวาคม 2564
- รายงานความพร้อมใช้งานของ GitHub: พฤศจิกายน 2564
- รายงานความพร้อมใช้งานของ GitHub: ตุลาคม 2564
- รายงานความพร้อมใช้งานของ GitHub: กันยายน 2564
- รายงานความพร้อมใช้งานของ GitHub: สิงหาคม 2564
- รายงานความพร้อมใช้งานของ GitHub: กรกฎาคม 2564
- รายงานความพร้อมใช้งานของ GitHub: มิถุนายน 2564
- รายงานความพร้อมใช้งานของ GitHub: พฤษภาคม 2564
- รายงานความพร้อมใช้งานของ GitHub: เมษายน 2564
- รายงานความพร้อมใช้งานของ GitHub: มีนาคม 2564
- รายงานความพร้อมใช้งานของ GitHub: กุมภาพันธ์ 2564
- รายงานความพร้อมใช้งานของ GitHub: มกราคม 2564
- รายงานความพร้อมใช้งานของ GitHub: ธันวาคม 2563
- รายงานความพร้อมใช้งานของ GitHub: พฤศจิกายน 2563
- รายงานความพร้อมใช้งานของ GitHub: สิงหาคม 2563
- รายงานความพร้อมใช้งานของ GitHub: กรกฎาคม 2020
- แนะนำรายงานความพร้อมใช้งานของ GitHub
- เดือนกุมภาพันธ์การวิเคราะห์หลังการวิเคราะห์เหตุการณ์
- 21 ตุลาคมการวิเคราะห์หลังเหตุการณ์
- รายงานเหตุการณ์ DDOS 28 กุมภาพันธ์
- รายงานเหตุการณ์: การเปิดเผยข้อมูลส่วนตัวโดยไม่ตั้งใจ
วิดีโอ
Gitlab
โพสต์บล็อก
- SRE นี้พยายามที่จะเปิดตัวการเปลี่ยนแปลงการกำหนดค่า haproxy คุณจะไม่เชื่อว่าเกิดอะไรขึ้นต่อไป ...
- สัปดาห์ของฉัน Shadowing วิศวกรความน่าเชื่อถือของไซต์ gitlab
- อัปเดต: บทเรียน Elasticsearch ที่เรียนรู้สำหรับการค้นหาระดับโลกขั้นสูง
- บทเรียนในการทำซ้ำจากทีมใหม่ในโครงสร้างพื้นฐาน
- วิธีที่เราเพิ่มประสิทธิภาพโครงสร้างพื้นฐานที่ Gitlab
- วิธีที่เราปรับขนาดการประมวลผลเวิร์กโหลด async ที่ gitlab.com โดยใช้ sidekiq
- Inside Gitlab: วิธีที่เราปล่อยแพทช์ซอฟต์แวร์
- สิ่งที่ติดตาม TCP Keepalives ที่หายไปสอนฉันเกี่ยวกับ Docker, Golang และ Gitlab
- วิธีที่เราใช้การจำลองแบบล่าช้าสำหรับการกู้คืนภัยพิบัติด้วย postgreSQL
ไร้สาระ
โพสต์บล็อก
- การปรับใช้ซอฟต์แวร์ที่ Gocardless: การเปิดตัวการสอน“ การเริ่มต้น” ของเรา
- วิธีที่เราบีบอัดข้อความย่อยผับ/อื่น ๆ และอื่น ๆ ประหยัดเงินจำนวนมาก
- การอพยพแบบ PostgreSQL ที่ปราศจากความกลัวสำหรับรางรถไฟ
- ความสามารถสังเกตได้ที่ Gocardless: เรื่องราวของการปรับปรุงประสิทธิภาพ API
- การดีบักการวางแผนการสืบค้น PostgreSQL
- zero -downtime postgres migrations - ส่วนที่ยาก
- ในการค้นหาประสิทธิภาพ - วิธีที่เราโกน 200ms ปิดคำขอโพสต์ทุกครั้ง
เหตุการณ์สำคัญและรายงานการวิเคราะห์
- รีวิวเหตุการณ์: บริการดับเมื่อวันที่ 25 ตุลาคม 2563, Vault TLS หมดอายุ
- รีวิวเหตุการณ์: API และ Dashboard ดับในวันที่ 10 ตุลาคม 2017
Godaddy
โพสต์บล็อก
- การปรับใช้ Kubernetes Gated
- ความลับภายนอกของ Kubernetes
- Kubernetes - บทนำที่ใช้งานได้จริงสำหรับนักพัฒนาแอปพลิเคชัน
- ไคลเอนต์ Node.js ที่ใช้งานง่ายสำหรับ Kubernetes API
Gojek
โพสต์บล็อก
- แนะนำ Skynet: โครงสร้างพื้นฐานเป็นรหัสสำหรับ Gojek
- ปรับขนาดบริการค้นหาทางภูมิศาสตร์ของเราสำหรับโหลด 10x
- ทำไมเราสาบานโดย RCA
- เราอัพเกรด Kubernetes บน GKE อย่างไร
- วิธีที่เราตรวจสอบ Apache Airflow ในการผลิต
Goldman Sachs
โพสต์บล็อก
- การเดินทางสังเกตการณ์ SecdB
- ความโกลาหลทดสอบแอปพลิเคชันบน AWS
- การพยากรณ์ความสามารถในการหยุดทำงานโดยใช้การเรียนรู้ของเครื่องเพื่อหนุนความยืดหยุ่นของแอปพลิเคชัน
- ให้ความพร้อมใช้งาน 99.9% และเวลาตอบสนองย่อยที่สองด้วย sybase IQ multiplexes โดยใช้ haproxy
- การสร้างความยืดหยุ่นหลายภูมิภาคด้วย Amazon RDS และ Amazon Aurora
- เปิดใช้งานกลุ่ม trino ที่มีอยู่สูงที่ Goldman Sachs
- ความสามารถในการสังเกตในระดับ
- โครงสร้างพื้นฐานและรูปแบบห่วงโซ่คำสั่ง
- Mobile CICD กับ EC2 MacOS
- ประกาศ catchit - สแกนเนอร์ซอร์สโค้ดซอร์สโค้ด
- แพลตฟอร์มอาคารสำหรับวิศวกรรมข้อมูล
Google
โพสต์บล็อก
- เร่งการตอบสนองของเหตุการณ์โดยใช้ AI Generative
- ข้อผิดพลาดและรูปแบบในการจัดการการพึ่งพา Microservice
- การปฏิบัติและกระบวนการของ SRE
- ความน่าเชื่อถือของเว็บไซต์ของ Google โดยใช้ GO
- ความต้องการสามเดือน 30 เท่า: วิธีที่เราปรับขนาด Google พบกันในระหว่าง COVID-19
- ห้องเรียน SRE: PubSub แบบกระจาย
- การจัดทีม SRE อย่างไรและจะเริ่มต้นได้อย่างไร
วิดีโอ
- อะไรคือความแตกต่างระหว่าง DevOps และ SRE? ด้วย Seth Vargo และ Liz Fong-Jones ของ Google
- งบประมาณความเสี่ยงและข้อผิดพลาดกับ Seth Vargo และ Liz Fong-Jones ของ Google
- ระบบอัตโนมัติในทางปฏิบัติ 'ด้วย Max Luebbe ของ GCP
- ต้องดู! - เพลย์ลิสต์ Google SRE YouTube
- วัตถุประสงค์ระดับ Squish: วิธีที่ SRE สามารถช่วยจัดงานด้านเทคนิคให้สอดคล้องกับผลประโยชน์ของผู้ใช้
- การใช้ฉันทามติแบบกระจาย
- SRE ฉันปรารถนาที่จะเป็น
- ห้องเรียน SRE หรือวิธีการออกแบบระบบกระจายที่เชื่อถือได้ใน 3 ชั่วโมง
- Zero Touch Prod: สู่สภาพแวดล้อมการผลิตที่ปลอดภัยและปลอดภัยยิ่งขึ้น
- แนวคิด ML ทั้งหมดของเราไม่ดี (และเราควรรู้สึกแย่)
- แผนที่ไม่ใช่ดินแดน: SLO นำเราไปหลงทางและสิ่งที่เราสามารถทำได้เกี่ยวกับมัน
- การปรับใช้แนวทางปฏิบัติที่ดีที่สุดในการฝึกอบรม SRE: วิธีที่เราทำโปรแกรมการศึกษา SRE ของเรา
- BigTable: การเดินทางจากไบนารีไปยังบริการและบทเรียนที่ได้เรียนรู้ไปพร้อมกัน
- เครื่องมือวัดเชิงปฏิบัติเพื่อการสังเกต
- ML OPS คืออะไร: โซลูชั่นและแนวทางปฏิบัติที่ดีที่สุดสำหรับ DevOps of Production ML Services
- การรายงานความน่าเชื่อถือของบริการแบบครบวงจร
- วิธีการแลกเปลี่ยนการใช้งานเซิร์ฟเวอร์และเวลาแฝงหาง
- รักษาความสมดุล: การโหลดบาลบอนในระดับอินเทอร์เน็ต demystified
- จากกล่องดำไปจนถึงปริมาณที่รู้จัก: วิธีการสร้างบริการ ML ที่คาดการณ์ได้และน่าเชื่อถือ
- สติใน SRE: การติดตามและแจ้งเตือนตัวเอง
- ระบบอัตโนมัติในทางปฏิบัติ
- Sublinear Scaling ในทางปฏิบัติ: โครงการ 1K SRE
- กลยุทธ์ในการแก้ไขข้อมูลการผลิต
- คำสาปของความเป็นอิสระของ SRE และวิธีการจัดการ
- การปรับขนาดองค์กร SRE: การเดินทางจาก 1 ไปยังหลายทีม
- ห้องเรียน SRE - วิธีการออกแบบระบบกระจายใน 3 ชั่วโมง
- การใช้ PRDS และการเดินทางของผู้ใช้เพื่อออกแบบเครื่องมือที่ใช้งานง่าย
- Google Sre และนักพัฒนาทำงานร่วมกันอย่างไร
- SRECON21 - การทดลองสำหรับ SRE
คว้า
โพสต์บล็อก
- การเดินทางของเราไปสู่การจัดส่งอย่างต่อเนื่องที่ Grab (ตอนที่ 1)
- การเดินทางของเราไปสู่การจัดส่งอย่างต่อเนื่องที่ Grab (ตอนที่ 2)
- การออกแบบระบบที่ยืดหยุ่น: เบรกเกอร์วงจรหรือลองใหม่? (ตอนที่ 1)
- การออกแบบระบบที่ยืดหยุ่น: เบรกเกอร์วงจรหรือลองใหม่? (ตอนที่ 2)
- การออกแบบระบบที่ยืดหยุ่นนอกเหนือจากการตอบกลับ (ตอนที่ 3): รูปแบบสถาปัตยกรรมและวิศวกรรมความโกลาหล
- ความวุ่นวายโดยใช้แพลตฟอร์มการทดลองของ Grab
- วิธีที่เราออกแบบโควต้า microservice เพื่อป้องกันการใช้ทรัพยากรในทางที่ผิด
- เราปรับขนาดแคชของเราและนอนหลับฝันดีได้อย่างไร
ไวยากรณ์
โพสต์บล็อก
- การปรับโครงสร้างพื้นฐาน AWS เพื่อรองรับหลายภูมิภาค
- การดำเนินงานด้านความปลอดภัยในสภาพแวดล้อม AWS
ความเอร็ดอร่อย
โพสต์บล็อก
- วัตถุประสงค์ระดับการบริการเพื่อความสงบของจิตใจ
- การดีบักยาพิษ sidekiq
รัศมี
โพสต์บล็อก
- วิศวกรรมความน่าเชื่อถือของไซต์สำหรับแอพมือถือดั้งเดิม
Heroku
โพสต์บล็อก
- The Adventures of Rendezvous ในสถาปัตยกรรมใหม่ของ Heroku
- การตอบสนองของเหตุการณ์ที่ Heroku
IBM
โพสต์บล็อก
- Site Reliability Engineering (SRE) คืออะไร?
- เครื่องมือและโซลูชั่น AIOPS
อย่างแท้จริง
โพสต์บล็อก
- SRE แน่นอน: รูปลักษณ์ภายใน
- มีความน่าเชื่อถือเพียงพอ
- กระบวนการเผยแพร่โดยอัตโนมัติ
- Sloth เครื่องมือในการกระตุ้นความล้มเหลวของเครือข่ายกับ Preetha Appan จาก Areder.com
วิดีโอ
- เราจะดีขึ้นหรือยัง? ก้าวหน้าไปสู่การดำเนินงานที่ปลอดภัยยิ่งขึ้น
อย่างแท้จริง
โพสต์บล็อก
- SRE Playbook - คู่มือปฏิบัติ
Khan Academy
โพสต์บล็อก
- วิธีการจัดการการจราจร 2.5x ในหนึ่งสัปดาห์ประสบความสำเร็จอย่างไร
- การพัฒนาโครงสร้างพื้นฐานเนื้อหาของเรา
LinkedIn
โพสต์บล็อก
- ทบทวนการคาดการณ์ความสามารถของไซต์ด้วยเครื่องวิเคราะห์ความสามารถ
- ข้อมูลเชิงลึกเกี่ยวกับทีมผลิตภัณฑ์ SRE ที่ LinkedIn
- การจ้าง SREs ที่ LinkedIn
- การอัปเดตโอเพ่นซอร์ส: School of SRE
- การแก้ไขการถดถอยประสิทธิภาพของระบบไฟล์ Linux
- การทดสอบการผลิตกับนกขมิ้นมืด
- การแจ้งเตือนอัจฉริยะใน ThirdEye ซึ่งเป็นแพลตฟอร์มการตรวจสอบแบบเรียลไทม์ของ LinkedIn
- Iris Mobile: โอเพ่นซอร์สอินเทอร์เฟซมือถือสำหรับการจัดการเหตุการณ์
- Linkedout: กรอบการฉีดความล้มเหลวระดับคำขอ
- กำจัดงานหนักด้วยการทดสอบโหลดอัตโนมัติอย่างเต็มที่
- การแต่งหน้าของทีม SRE ที่กระจายทางภูมิศาสตร์ที่ประสบความสำเร็จ: ตอนที่ 1
- การแต่งหน้าของทีม SRE ที่กระจายทางภูมิศาสตร์ที่ประสบความสำเร็จ: ตอนที่ 2
- Project Star*: ปรับปรุงกระบวนการโทรของเรา
- ทำให้ OnCall ของคุณเป็นไปโดยอัตโนมัติ: การจัดหา Fossor และ Ascii Etch
- วิศวกรรมความยืดหยุ่นที่ LinkedIn กับ Project Waterbear
- การจ้าง SRES ที่ LinkedIn, 2017
- เปิดการจัดหาไอริสและ Oncall
- การสร้างวัฒนธรรม SRE ที่ LinkedIn
- ความล้มเหลวไม่ใช่ตัวเลือก
- MTTD และ MTTR เป็นกุญแจสำคัญ
- สิ่งที่ได้รับการวัดได้รับการแก้ไข
วิดีโอ
- การเติบโตของทีมความน่าเชื่อถือของไซต์ที่ LinkedIn: การจ้างงานยาก - Greg Leffler
- 9 ปีแห่งความล้มเหลว: การแข่งรถเส็งเคร็งทำให้ฉันเป็น SRE ที่ดีขึ้นได้อย่างไร
- การผุกร่อนพายุ: คำเตือนล่วงหน้าช่วยประหยัดฟาร์มได้อย่างไร
- unconference: ปัญหาที่ยังไม่ได้รับการแก้ไขใน SRE
- นำโดยไม่ต้องจัดการ: เป็นผู้นำด้านเทคนิคของ SRE
- ทำไมการตรวจสอบ (ของฉัน) จึงดูด?
- การพยากรณ์การจราจรและโครงสร้างพื้นฐานการทดสอบความเครียด
- การมีสติโดยรวมสำหรับการตัดสินใจที่ดีขึ้นใน SRE
- TCP - สถาปัตยกรรมการปรับปรุงและการปรับแต่ง
- สมาชิกกว่า 600 ล้านคนและบริการไมโครหลายร้อยรายการ: วิธีที่เราปรับขนาดระบบการตรวจสอบของเราเพื่อให้ทัน
- การทำความเข้าใจการวัดทางธุรกิจสามารถทำให้คุณเป็น SRE ที่ดีขึ้นได้
- Code-Yellow: ช่วยให้การดำเนินงานทีมที่หนักหน่วงที่สุดอย่างชาญฉลาด
- ความแตกต่างในการใช้งาน SRE ใน บริษัท ต่างๆ
เครื่องมือ
หอก
โพสต์บล็อก
- รุ่น Manager Release
- ทีม SRE #8: Loggi
Loveholidays
โพสต์บล็อก
- การกำหนดเส้นทางการแจ้งเตือนแบบไดนามิกกับ Prometheus และ AlertManager
- ทำให้ Loveholidays เร็วขึ้น 18% ด้วย http/3
- การบังคับใช้แนวปฏิบัติที่ดีที่สุดเกี่ยวกับโครงสร้างพื้นฐานการบริการตนเองด้วย Terraform, Atlantis และนโยบายเป็นรหัส
- หลักการ 5 ข้อที่ช่วยขยายความรัก
- บันทึกอย่างรวดเร็วแบบเรียลไทม์กับ Grafana Loki ในราคาต่ำกว่า $ 1 ต่อวัน
Macquarie
โพสต์บล็อก
- การเดินทาง devsecops ของเรากับ Golang
- การกำหนดค่าไปป์ไลน์เป็นรหัสด้วย kotlin
- Devops และการแยกหน้าที่
- Macquarie โอบกอด Devops
- ปรับสเกลแพลตฟอร์ม Kubernetes ทั่วทั้งองค์กร
มากที่สุด
โพสต์บล็อก
- การตรวจสอบสภาพแวดล้อมคลาวด์ในระดับด้วยโพรและธานอส
- วิธีที่เราใช้ Sloth ในการตรวจสอบ SLO และแจ้งเตือนด้วย Prometheus
Meituan (美团)
โพสต์บล็อก
- การพัฒนาและการปฏิบัติของ SRE ในคลาวด์ (云端的 sre 发展与实践)
Mercari
โพสต์บล็อก
- ใครดู Watchmen? จับตาดูระบบการตรวจสอบของเรา
- สิ่งที่ทีม Microservices SRE กำลังทำในฐานะผู้เผยแพร่ศาสนา SRE
- การทำงานเป็น microservices แบบฝังตัวเป็นอย่างไร
- ทีม Merpay SRE: อดีตและอนาคต
- ฝัง SRE ที่ Mercari
- สิ่งที่ทีม SRE ต้องการบรรลุกับทีมพัฒนา
- DevSecops: มันคืออะไรและทำไมมันถึงได้รับแรงผลักดันในอุตสาหกรรม?
- เราจะแบ่งปันทักษะการแก้ไขปัญหาได้อย่างไร
- Datadog Dashboard ที่สเกล w / terraform
เมตา
โพสต์บล็อก
- ใช้ประโยชน์จาก AI สำหรับการตอบสนองเหตุการณ์ที่มีประสิทธิภาพ
- การปรับปรุงเวิร์กโฟลว์ SLO ของ Meta ด้วยคำอธิบายประกอบข้อมูล
- Slick: การใช้ SLOs เพื่อความน่าเชื่อถือที่ดีขึ้น
- รายละเอียดเพิ่มเติมเกี่ยวกับการดับ 4 ตุลาคม
- อัปเดตเกี่ยวกับการดับ 4 ตุลาคม
วิดีโอ
- แนวทางการบริการลูกค้าของ SRE
- อย่างไร (ไม่) ในการขยายโครงการ: โพสต์ชันสูตร
- ปล่อยไซต์งูหลามที่ใหญ่ที่สุดในโลกทุก ๆ 7 นาที
- การใช้ ML เพื่อจัดหมวดหมู่ข้อผิดพลาดแบบไดนามิกโดยอัตโนมัติ
Microsoft
วิดีโอ
- Sli & Deliable Deep Dive 'กับ David N. Blank-Edelman แห่ง Microsoft
- การใช้อัตโนมัติของระบบอัตโนมัติ: ตลกในสามส่วน 'กับ Tanner Lund of Microsoft
- วิศวกรรมซอฟต์แวร์ที่ยั่งยืนและ SRES
- ศึกษาปัจจัยมนุษย์และวัฒนธรรมของทีมเพื่อปรับปรุงความเหนื่อยล้าของเพจเจอร์
- จัดลำดับความสำคัญความน่าเชื่อถือในขณะที่สร้างแอปพลิเคชัน
- การสร้างความยืดหยุ่น: วิธีการเรียนรู้เพิ่มเติมจากเหตุการณ์
- เรื่องราวของการชันสูตรศพสองเรื่อง: มุมมองของมนุษย์
- ความพร้อมใช้งาน - คิดเกิน 9s
- การใช้ระบบอัตโนมัติ: ตลกในสามส่วน
- ops ใน serverless
มิโร่
โพสต์บล็อก
- Prometheus มีความพร้อมใช้งานสูงและกลยุทธ์การยอมรับข้อผิดพลาดการจัดเก็บระยะยาวด้วย Victoriametrics
- การจัดการเซิร์ฟเวอร์หลายร้อยตัวสำหรับการทดสอบโหลด: การตรวจสอบอัตโนมัติ, การตรวจสอบที่กำหนดเอง, วัฒนธรรม DevOps
- การทดสอบโหลดที่เชื่อถือได้เกี่ยวกับความแตกต่างที่ไม่คาดคิด
มอนโซ่
โพสต์บล็อก
- Autoscaling Monzo: วิธีที่เราเพิ่มประสิทธิภาพแพลตฟอร์มของเราให้มีขนาดที่เหมาะสม
- เรามีวิวัฒนาการทางโทรศัพท์ที่ Monzo อย่างไร
- เราตอบสนองต่อเหตุการณ์อย่างไร
- เราตรวจสอบ Monzo อย่างไร
วิดีโอ
- ในที่สุดการค้นพบบริการที่สอดคล้องกัน
เครื่องมือ
netflix
โพสต์บล็อก
- บรรลุความสามารถในการสังเกตในเวิร์กโฟลว์ async
- การสร้างโครงสร้างพื้นฐานการติดตามแบบกระจายของ Netflix
- บทเรียนจากเครื่องมือสร้างความสามารถในการสร้างที่ Netflix
- เอ็ดการ์: การแก้ปริศนาที่เร็วขึ้นด้วยความสามารถสังเกตได้
- TellTale: การตรวจสอบแอปพลิเคชัน Netflix ง่ายขึ้น
- ทำให้ลูกค้าสตรีมมิ่ง - การปฏิบัติที่น่าเชื่อถือของไซต์ส่วนกลางที่ Netflix
- แนะนำการจัดส่ง
- การใช้รูปแบบ Netflix Devops กับ Windows
- Chap: แพลตฟอร์มระบบอัตโนมัติ Chaos
- เริ่มต้นหิมะถล่ม
- Netflix Chaos Monkey ได้อัพเกรด
- ความโกลาหลวิศวกรรมอัพเกรด
- การทดสอบความล้มเหลวอัตโนมัติ
- จากความวุ่นวายในการควบคุม - การทดสอบความยืดหยุ่นของแพลตฟอร์มการค้นพบเนื้อหาของ Netflix
- แนะนำ Atlas: แพลตฟอร์ม telemetry หลักของ Netflix
- พอดี: การทดสอบการฉีดล้มเหลว
- ประกาศความปลอดภัยลิง - การตรวจสอบและวิเคราะห์การกำหนดค่าความปลอดภัยของ AWS
- บทเรียน Netflix เรียนรู้จากการหยุดทำงานของ AWS
- Scryer: เอ็นจิ้นการปรับสเกลอัตโนมัติของ Netflix
เหตุการณ์สำคัญและรายงานการวิเคราะห์
- หลังการชันสูตรของวันที่ 22 ตุลาคม 2012 AWS Degradation
วิดีโอ
- AWS RE: ประดิษฐ์ 2019: A Day in the Life of A Netflix Engineer (NFX202)
- เมื่อใด /bin /sh การโจมตี: กลับมาอีกครั้ง "ทำให้ทุกสิ่งดำเนินการโดยอัตโนมัติ"
- สิ่งต่างๆถูกต้องได้อย่างไร? เรียนรู้เพิ่มเติมจากเหตุการณ์
- การตรวจสอบและการติดตาม @Netflix การสตรีมข้อมูลโครงสร้างพื้นฐาน
- การตรวจสอบประสิทธิภาพของผู้ใช้จริงที่ Netflix Scale - Martin Spier
- AWS Re: Invention 2017 - Nora Jones อธิบายว่าทำไมเราต้องการความวุ่นวายมากขึ้น - Chaos Engineering นั่นคือ
- AWS RE: Invent 2017: การแสดงความโกลาหลที่ Scale Netflix (Dev334)
- Netflix: ความยืดหยุ่นหลายภูมิภาคและ Amazon Route 53
- การออกแบบบริการเพื่อความยืดหยุ่น: บทเรียน Netflix
- South Bay Sre Meetup - ทีมงาน Netflix Cloud Performance
- AWS Re: Invention 2017: A Day in the Life of A Netflix Engineer III (ARC209)
- วิธีที่ Netflix ใช้ Kinesis Streams เพื่อตรวจสอบแอปพลิเคชันและวิเคราะห์กระแสการจราจรหลายพันล้านครั้ง
- Mastering Chaos - คู่มือ Netflix สำหรับ Microservices
- AWS Re: Invent 2016: จาก Resilience to ubiquity - #NetflixEverywhere Global Architecture (ARC204)
- SRECON 2016 - Netflix: 190 ประเทศและ 5 CORE SRES
- จากผู้ดูแลระบบ SYS ไปยัง Netflix SRE
- แอปพลิเคชันวิศวกรรมความยืดหยุ่นและการดำเนินงานที่ Netflix กับ Hystrix
- การฉีดล้มเหลวที่ Netflix
- LISA13 - Netflix รวบรวมความล้มเหลวในการปรับปรุงความยืดหยุ่นและเพิ่มความพร้อมใช้งานสูงสุด
- การจัดการเหตุการณ์ที่ความเร็ว Netflix
พอดคาสต์
- Ryan Kitchens เกี่ยวกับการเรียนรู้จากเหตุการณ์ที่ Netflix บทบาทของ SRE และ Sociotechnical Systems
เครื่องมือ
ใหม่ของที่ระลึก
โพสต์บล็อก
- การกำหนดบทบาทซอฟต์แวร์ที่ทันสมัย: SREs at New Relic
- 10 สิ่งที่ทุกคนต้องรู้เกี่ยวกับวิศวกรรมความน่าเชื่อถือของไซต์ (SRE)
- วิศวกรความน่าเชื่อถือของไซต์ใช้เครื่องมืออะไร
- วันหนึ่งในชีวิตของ Relic Sre ใหม่
- 7 นิสัยของวิศวกรความน่าเชื่อถือของไซต์ที่ประสบความสำเร็จอย่างสูง
- ใช้การปฏิบัติของ SRE
- การใช้การสังเกตที่ทันสมัยเพื่อสร้างวัฒนธรรมที่ขับเคลื่อนด้วยข้อมูล
นูเบกส์
โพสต์บล็อก
- ความเป็นเลิศด้านการดำเนินงานทางวิศวกรรมซึ่งเป็นกรณีของการปรับปรุงอย่างต่อเนื่อง
- เราจัดการกับเหตุการณ์ทางเทคนิคอย่างไร
- เราทำการหมุนสายได้อย่างไรที่ Nubank
- วิธีที่เราขยายแพลตฟอร์มข้อมูลของเราอย่างมีประสิทธิภาพและน่าเชื่อถือ
- ทำไมเราถึงฆ่าชุดทดสอบแบบ end-to-end ของเรา
- การฝึกอบรมอัตโนมัติสำหรับรูปแบบการเรียนรู้ของเครื่อง: เคล็ดลับและบทเรียนที่ได้เรียนรู้
Openai
โพสต์บล็อก
- 20 มีนาคม CHATGPT OUTAGE: นี่คือสิ่งที่เกิดขึ้น
- Openai Sre และ Scaling อธิบายได้ง่าย
- ปรับขนาด Kubernetes เป็น 2,500 โหนด
- ปรับขนาด Kubernetes เป็น 7,500 โหนด
- ปรับขนาดโครงสร้างพื้นฐาน AI ที่ openai
paypal
โพสต์บล็อก
- ทริกเกอร์: เหตุการณ์ #1234 (กระบวนการเหตุการณ์จำเป็นต้องแก้ไข)
- การใช้งานการสังเกตในตาข่ายบริการ
- PostgreSQL ที่ระดับ: การเปลี่ยนแปลงสคีมาฐานข้อมูลโดยไม่ต้องหยุดทำงาน
- ปรับขนาด GraphQl ที่ PayPal
วิดีโอ
- SRECON สนทนาเอเชีย/แปซิฟิกกับ Karthikeyan Selvaraj และ Rajesh Ramachandran, Paypal
- จากนั้น SRE VS SRE ตอนนี้: การกระทำที่สมดุลระหว่างการตอบสนองและสัญชาตญาณที่ใช้งานง่ายที่ PayPal
- การตรวจจับความเสื่อมโทรมของบริการและความล้มเหลวในระดับผ่านการประมวลผลบันทึกแบบกระจาย
- ใช้งาน Elasticsearch ได้อย่างง่ายดายในระดับ
- สร้างความมั่นใจในความน่าเชื่อถือของไซต์ผ่านการควบคุมความปลอดภัย
ปิกนิก
โพสต์บล็อก
- ไมโครมิเตอร์และสแต็กการสังเกตที่ทันสมัย
- การตรวจสอบและการสังเกตที่ปิกนิก
Pinterest
โพสต์บล็อก
- สร้างความมั่นใจในการใช้งานบริการสตรีมมิ่งแบบเรียลไทม์ที่มีอยู่ในระดับสูง
- การปรับปรุงประสิทธิภาพและลดรันไทม์โดยใช้การเพิ่มประสิทธิภาพการอ่าน S3
- ปรับขนาด kubernetes ด้วยการประกันที่ pinterest
- สิ่งที่เราเรียนรู้จากเหตุการณ์ ooms แอพ iOS
- วิธีที่เราออกแบบระบบการรวมอย่างต่อเนื่องของเราให้เร็วกว่า 50%
- ทำให้การปรับใช้เว็บง่ายขึ้น
- การอัพเกรดตัวชี้วัดการปฏิบัติงานของ Pinterest
- การติดตามแบบกระจายที่ Pinterest ด้วยเครื่องมือโอเพ่นซอร์สใหม่
- Pinterest ปรับขนาดอัตโนมัติ
วิดีโอ
- การสร้างความเป็นเจ้าของรหัสที่สามารถดำเนินการได้
- วิวัฒนาการของเครื่องมือการสังเกตที่ Pinterest
- การอัพเกรด OS/แพลตฟอร์มอัตโนมัติสำหรับเจ้าของบริการ
บุรุษไปรษณีย์
โพสต์บล็อก
- เรียนรู้ว่ากลุ่ม Kubernetes ของคุณตอบสนองต่อความล้มเหลวโดยใช้ Gremlin และ Grafana
prezi
โพสต์บล็อก
- วิธีหลีกเลี่ยงการดับทั่วโลก - การย้ายป้าย Daemonset อย่างราบรื่น
- ในการค้นหาความเร็ว - การดีบักประสิทธิภาพ Elasticsearch
- Prometheus at Prezi: แทนที่ 10 ปีของการต่อต้านรูปแบบ
หมวกสีแดง
โพสต์บล็อก
- จาก OPS ถึง SRE: วิวัฒนาการของทีมงาน OpenShift
- 5 การปฏิบัติที่คล่องตัวทุกทีม SRE ควรนำมาใช้
- 7 แนวทางปฏิบัติที่ดีที่สุดสำหรับการเขียนผู้ประกอบการ Kubernetes: มุมมอง SRE
เกมจลาจล
โพสต์บล็อก
- ตำนานของ Runeterra CI/CD Pipeline
- กลยุทธ์สำหรับการทำงานในระบบที่ไม่แน่นอน
- ปรับปรุงประสบการณ์นักพัฒนาซอฟต์แวร์สำหรับบริการปฏิบัติการ
- ความสามารถในการปรับขนาดและการทดสอบโหลดสำหรับความกล้าหาญ
- ใช้ประโยชน์จาก Golang สำหรับการพัฒนาเกมและการดำเนินงาน
- ควบคุมความโกลาหลด้วยการทดสอบการฉีดข้อผิดพลาด
- ลงไปในหลุมกระต่ายของการตรวจสอบประสิทธิภาพ
- การทำโปรไฟล์: กรณีของมิลลิวินาทีที่หายไป
- การทำโปรไฟล์: การแสดงในโลกแห่งความเป็นจริงในลีก
- การทำโปรไฟล์: การเพิ่มประสิทธิภาพ
- การทำโปรไฟล์: การวัดและการวิเคราะห์
- ใช้บริการออนไลน์ที่ Riot: Part I
- ใช้บริการออนไลน์ที่ Riot: ตอนที่สอง
- ใช้บริการออนไลน์ที่ Riot: ส่วนที่สาม
- ใช้บริการออนไลน์ที่ Riot: ส่วนที่สาม: ส่วน Deux
- ใช้บริการออนไลน์ที่ Riot: ส่วนที่ 4
- ใช้บริการออนไลน์ที่ Riot: ส่วนที่ V
- วิวัฒนาการของความปลอดภัยที่ Riot
- เรียกใช้ไปป์ไลน์ทดสอบอัตโนมัติสำหรับการอัปเดตไคลเอนต์ลีก
- การทดสอบอัตโนมัติสำหรับ League of Legends
พนักงานขาย
โพสต์บล็อก
- ดูที่ระนาบควบคุม Kubernetes สำหรับการเช่าหลายครั้ง
- การเพิ่มประสิทธิภาพเครือข่าย EKS สำหรับสเกล
- การติดตั้งโหนดการหยุดทำงานเป็นศูนย์ในคลัสเตอร์ Kubernetes
- ยังไงไม่ใช่เหตุผล: ทางเลือกแทนห้า wys สำหรับการชันสูตรศพ
- หัวฉีด sidecar ทั่วไปสำหรับ Kubernetes
- การดำเนินการตามกลยุทธ์การตรวจสอบสำหรับผลิตภัณฑ์ตาม Microservices
- 10 ขั้นตอนในการพัฒนาแผนการตอบสนองเหตุการณ์ที่คุณจะใช้จริง
- การเดินทางของเราไปยังท่อบันทึกที่สมบูรณ์แบบ
- เพิ่มประสิทธิภาพประสิทธิภาพกับผู้ทำงานบนเว็บ
- ใช้เวลาสักครู่เพื่อมุ่งเน้น
สื่อ Schibsted
โพสต์บล็อก
- วิศวกรรมความน่าเชื่อถือสำหรับบางเว็บไซต์ 10 อันดับแรกในสแกนดิเนเวีย
นักเขียน
โพสต์บล็อก
- การเรียนรู้จากเหตุการณ์: การเตรียม sidekiq พร้อมที่จะรับใช้งานพันล้านงาน
- ข้อความรับรองสำหรับการใช้ pagerduty ที่ scribd
- มอบหมายหน้าที่เพจเจอร์ให้กับนักพัฒนา
มีร้านขายสินค้า
โพสต์บล็อก
- การวางแผนความยืดหยุ่นสำหรับกิจกรรมการจราจรสูง
- การวางแผนกำลังการผลิตในระดับ
- การใช้ DNS Traffic Management เพื่อเพิ่มความยืดหยุ่นให้กับบริการของ Shopify
- สี่ขั้นตอนในการสร้างการทดสอบวันเกมที่มีประสิทธิภาพ
- การใช้ Chatops ในขั้นตอนการจัดการเหตุการณ์ของเรา
- Statsd ที่ Shopify
วิดีโอ
- การตรวจสอบเครือข่าย: เรื่องราวของการยอมรับช่องว่างการสังเกต
- คาดหวังสิ่งที่ไม่คาดคิด: การเตรียมทีม SRE สำหรับการตอบสนองต่อความล้มเหลวของนวนิยาย
- คณิตศาสตร์ผ้าเช็ดปากขั้นสูง: การประมาณประสิทธิภาพของระบบจากหลักการแรก
การเดิมพัน Sky และการเล่นเกม
โพสต์บล็อก
- มันเป็นเพียงการเปลี่ยนแปลงการตรวจสอบ
- “ อะไรคือสิ่งที่เลวร้ายที่สุดที่อาจเกิดขึ้นได้”: ตัวอย่างการทำงานของวิธีที่เราจัดการกับเหตุการณ์สด
- เพิ่มขึ้นจากขี้เถ้า
- ชน! ปัง วอลล็อต การฝึกฝนทำให้สมบูรณ์แบบ
- ประสิทธิภาพซ้ายขวาและตรงกลาง
หย่อน
โพสต์บล็อก
- เหตุการณ์ของ Slack ในวันที่ 2-22-22
- การสังเกตโครงสร้างพื้นฐานสำหรับการเปลี่ยนเส้นโค้งการใช้จ่าย
- ไฟดับของ Slack ในวันที่ 4 มกราคม 2021
- วันที่น่ากลัวน่ากลัวไม่ดีและแย่มากที่ Slack
- ปรับใช้ที่ Slack
- Disasterpiece Theatre: กระบวนการของ Slack สำหรับวิศวกรรม Chaos ที่เข้าถึงได้ง่าย
วิดีโอ
- หย่อนที่ขอบ
- สิ่งที่ทำลายระบบของเรา: อนุกรมวิธานของหงส์ดำ
Slalom Build
โพสต์บล็อก
- วิธีการใช้วัตถุประสงค์ระดับการบริการใน APM ใหม่
- คู่มือผู้เริ่มต้นถึง DevOps: วิธีการทำให้เข้าสู่อุตสาหกรรม
- การกระทำของ GitHub: Beyond CI/CD
- เหตุใดการทดสอบอัตโนมัติทั้งหมดจึงไม่ทำงานบนท่อ?
- รูปร่างของวิศวกรรมความน่าเชื่อถือของไซต์หลายรูปแบบ
- วิธีสร้างคลัสเตอร์ Kubernetes ที่ปลอดภัยโดยเริ่มต้นด้วยท่อส่ง CI/CD พื้นฐานบน AWS
- สถาปัตยกรรมการจัดการลับ: การค้นหาความสมดุลระหว่างความปลอดภัยและความซับซ้อน
- ตรวจจับคำขอที่เป็นอันตรายด้วย Keras & Tensorflow
- LEGO MONOLITH - การพิสูจน์แนวคิดของแนวคิด microservice
- การจัดการความลับโดยใช้ Hashicorp Vault
- แพ็คเกจสปริงบูตแอปพลิเคชันสำหรับการปรับใช้บน Kubernetes
- โครงสร้างพื้นฐานที่ไม่เปลี่ยนรูปและการส่งมอบอย่างต่อเนื่องในระบบคลาวด์
SoundCloud
โพสต์บล็อก
- วิธีการมอบระบบให้ประสบความสำเร็จ
- การสร้างวัฒนธรรมที่มีสุขภาพดี
- การแจ้งเตือนเกี่ยวกับ slos เหมือนข้อดี
- การปรับใช้งานด้วย Canary
- โพรมีอายุมาแล้ว-สะท้อนให้เห็นถึงการพัฒนาโครงการโอเพ่นซอร์ส
- Prometheus: การตรวจสอบที่ SoundCloud
- สิ่งที่ฉันเรียนรู้ในหนึ่งปีในฐานะผู้ฝึกงาน SRE
- การทดสอบภายใต้เลนส์ขยาย
ทำให้เป็นสปอต
โพสต์บล็อก
- Matt Clarke: วิศวกรโครงสร้างพื้นฐานอาวุโส
- การออกแบบประสบการณ์ Kubernetes ที่ดีขึ้นสำหรับนักพัฒนา
- TechBytes: สิ่งที่อุตสาหกรรมคิดถึงเกี่ยวกับเหตุการณ์และสิ่งที่คุณสามารถทำได้
- โครงสร้างพื้นฐานการตอบสนองของเหตุการณ์อัตโนมัติใน GCP
วิดีโอ
- การติดตามรวดเร็วและช้า: ขุดและปรับปรุงประสิทธิภาพของบริการเว็บของคุณ
Squarespace
Blog Posts
- Under the Hood: Ensuring Site Reliability
Videos
- Pushing through Friction
- How to SRE When Everything's Already on Fire
- Case Study: Implementing SLOs for a New Service
- Creating a Code Review Culture
Stack Overflow
Blog Posts
- “This should never happen. If it does, call the developers.”
- Infrastructure as code: Create and configure infrastructure elements in seconds
- Fulfilling the promise of CI/CD
- A deeper dive into our May 2019 security incident
- Guest Post - Failing over without falling over
- How We Built Our Blog
- Stack Overflow Frees Up Engineering Time with Netlify
Videos
- Low Context DevOps: Improving SRE Team Culture through Defaults, Documentation, and Discipline
Strava
Blog Posts
- Scaling Club Leaderboard Infrastructure for Millions of Users
- Distributed Tracing at Strava
แถบ
Blog Posts
- Fast and flexible observability with canonical log lines
- Fast builds, secure builds. Choose two.
- Introducing Veneur: high performance and global aggregation for Datadog
Videos
- How Stripe Invests in Technical Infrastructure
- The AWS Billing Machine and Optimizing Cloud Costs
เป้า
Blog Posts
- Ɔhaos Ǝnginǝǝring @ Target - Part 2
- Ɔhaos Ǝnginǝǝring @ Target - Part 1
- GoAlert - Your Future Open Source, On-Call Notification Product
Teads
Blog Posts
- Scaling your on-duty team
Tinder
Blog Posts
- The Ultimate Load Test
- How We Improved Our Performance Using ElasticSearch Plugins: Part 1
- How We Improved Our Performance Using ElasticSearch Plugins: Part 2
- Tinder's move to Kubernetes
Tokopedia
Blog Posts
- Benefits of benchmarking with Go
- Simulating Customized Chaos in Golang using Toxiproxy
- How Tokopedia Rank Millions of Products in Search Page
Trivago
Blog Posts
- How To Get Fooled By Metrics
ทวิตเตอร์
Blog Posts
- Twilio SRE Gameday Template
Twitter
Blog Posts
- Logging at Twitter: Updated
- Deleting data distributed throughout your microservices architecture
- Deterministic Aperture: A distributed, load balancing algorithm
- MetricsDB: TimeSeries Database for storing metrics at Twitter
- The Infrastructure Behind Twitter: Scale
- The infrastructure behind Twitter: efficiency and optimization
Uber
Blog Posts
- Founding Uber SRE
- Disaster Recovery for Multi-Region Kafka at Uber
- Engineering Failover Handling in Uber's Mobile Networking Infrastructure
- Optimizing Observability with Jaeger, M3, and XYS at Uber
Videos
- A Tale of Two Rotations: Building a Humane & Effective On-Call
- Testing in Production at Scale
- A History of SRE at Uber' with Rick Boone of Uber
Udemy
Blog Posts
- Blameless Incident Reviews at Udemy
- How Udemy does Build Engineering
upGrad
Blog Posts
- Web Performance and Related Stories — upgrad.com
- Beginner's guide to web analytics
- iOS Continuous Deployment with Bitbucket, Jenkins and Fastlane at UpGrad
VGW
Blog Posts
- The SRE Incident Response game
Videos
- Level Up Your Incident Response With Gameplay
Wikimedia Foundation
Videos
- Testing Encyclopedias in Production
- What Happens When You Type en.wikipedia.org?
wix
Blog Posts
- How We Improved Website Performance by Evolving Our Infrastructure
- Wix Inbox Journey: 3 Approaches for Zero Downtime Database Migration
- Moving Velo to Multiple Container Sites: The Why, The How and The Lessons Learned
- Making Order in CI/CD Mess
Yelp
Blog Posts
- The process: Implementing Yelp's failover strategy
Videos
- Yelp - What I Wish I Knew before Going On-Call
Zalando
Blog Posts
- Tracing SRE's journey in Zalando - Part I
- Tracing SRE's journey in Zalando - Part II
- Tracing SRE's journey in Zalando - Part III
Zerodha
Blog Posts
- Infrastructure monitoring with Prometheus at Zerodha
- Logging at Zerodha
Zomato
Blog Posts
- Huddle Diaries – DevOps and Data Platform
SRECon Mix Playlist
Videos
- Adobe - The Good, the Bad and the Ugly: The 3 Learnings of an SRE
- Amdocs - SREs at Telecom and Media Industry: Bridging between Legacy and Cloud Native Apps
- Amazon - Confessions of a Systems Engineer: Learning from My 20+ Years of Failure
- Alaska Airlines - Capacity Prediction in External Services
- BuzzFeed - Optimizing for Learning
- BT - Challenges of Starting an SRE Team from Scratch in an Enterprise
- Cloudflare - Support Operations Engineering: Scaling Developer Products to the Millions
- Cloudlock - My Life as a Solo SRE
- Hudson River Trading - Fixing On-Call When Nobody Thinks It's (Too) Broken
- IBM - Why Automating Everything Adds to Your Toil
- Genesys - The Smallest Possible SRE Team
- Grafana Labs - SRE in the Third Age
- Kenna Security - Building a Scalable Monitoring System
- Lightstep - Building Service Ownership Using Documentation, Telemetry, and a Chance to Make Things Better
- MessageBird - Autopsy of a MySQL Automation Disaster
- Netlify - Perks and Pitfalls of Building a Remote First Team
- ReactiveOps - Zero to SRE
- Salesforce - Incident Response in Unfamiliar Sociotechnical Systems: One Incident Commander's Challenges Supporting Inter-organizational Anomaly Response in the Age of COVID-19
- Sprax - From Nothing to SRE: Practical Guidance on Implementing SRE in Smaller Organisations
- The New York Times - SRE by Influence, Not Authority: How the New York Times Prepares for Large-Scale Events
- Twitter - Hiring Great SREs
- United States Digital Service - Lessons Learned in Black Box Monitoring 25,000 Endpoints and Proving the SRE Team's Value
- Unity Technologies - Being Reasonable about SRE
- Udemy - How to Do SRE When You Have No SRE
- Vanguard - Cloudy with a Chance of Chaos
- WeWork - Learning from Learnings: Anatomy of Three Incidents
- Zendesk - Latency and Availability Error Budgets Done Right at Scale
ทรัพยากร
หนังสือ
- ใหม่! Enterprise Roadmap to SRE
- Building Secure & Reliable Systems | Read free online version hosted by Google
- Site Reliability Engineering | Read free online version hosted by Google
- The Site Reliability Workbook from Google | Read free online version hosted by Google
- Training Site Reliability Engineers | Read free online version hosted by Google
- 97 Things Every SRE Should Know | Complimentary Copy from Nginx
- SLO Adoption and Usage in Site Reliability Engineering
- Practical Site Reliability Engineering
- Implementing Service Level Objectives
- Chaos Engineering
- Seeking SRE
- Security Chaos Engineering
- Chaos Engineering Observability
- Database Reliability Engineering
- What Is SRE?
- Database Reliability Engineering: What, Why, and How?
- Observability Engineering
- Chaos Engineering: Site reliability through controlled disruption
- Incident Metrics in SRE | Read free online version hosted by Google
- Engineering Reliable Mobile Applications
- Monitoring the SRE Golden Signals
- Site Reliability Engineering: Philosophies, habits, and tools for SRE success | Portable version
- 97 Things Every Cloud Engineer Should Know
- Real-World SRE
- Hands-on Site Reliability Engineering
เหตุการณ์
- SRECon Past Events
- ChaosConf
- SLOConf
- cdCon
- cdCon 2021 Playlist
- cdCon 2020 Playlist
- Conf42
ทรัพยากรอื่น ๆ
Awesome Lists
- Awesome SRE
- Awesome Site Reliability Engineering Tools
- Awesome Chaos Engineering
- Awesome Monitoring
- Awesome Observability
- Awesome MLOps
- ML-Ops.org
SRE Resources from various organizations
- Google SRE Page
- Google SRE Classroom
- Google Cloud SRE Page
- Microsoft SRE Page
- School of SRE from LinkedIn
- Stripe Increment Magazine Issue 16 on Reliability
- AWS Observability Recipes
- Awesome Sysadmin
Incidents & postmortems
- The Verica Open Incident Database
- Postmortem Templates
- Incident Review and Postmortem Best Practices
จดหมายข่าว
- SRE Weekly Newsletter
- Chaos Engineering Newsletter
- DevOps Weekly Newsletter
การให้เครดิต
- Inspired by Howtheytest from Abhijeet Vaikar
- The list of organizations is referred from my other repo awesome-engineering
- Banner image Cartoon vector created by vectorjuice - www.freepik.com
Other How They... repos
- Howtheytest
- Howtheydevops
- Howtheyaws
ผู้มีส่วนร่วม
มีส่วนช่วย
Contributions welcome! Read the contribution guidelines first.
Stargazers Over Time
ใบอนุญาต
To the extent possible under law, Unmesh Gundecha has waived all copyright and related or neighboring rights to this work.
If you decide to use this anywhere, please credit @upgundecha on X. Also, if you like my work, check out my other projects on GitHub.