A DevOps focus on collaboration evolves into a NoOps focus on automation. But there is no magic — in this ambitious NoOps future, operations professionals must utilize infrastructure, working differently to enable developers to achieve better outcomes with less manual intervention.
http://perfcap.blogspot.com/2012/03/ops-devops-and-noops-at-netflix.html There is no ops organization involved in running our cloud, no need for the developers to interact with ops people to get things done, and less time spent actually doing ops tasks than developers would spend explaining what needed to be done to someone else.
https://gist.github.com/jallspaw/2140086 Like many have pointed out, the issue people have with "NoOps" is the presence of "No" in it. This is because you (and others) are intermingling titles (and therefore organizational groups) with the often blurred domain expertise usually (but not evenly-distributed across a diverse spectrum of organizations) associated with Operations.
SRE, we want to spend time on long-term engineering project work instead of operational work. Because the term operational work may be misinterpreted, we use a specific word: toil. 〜（中略）〜 So what is toil? Toil is the kind of work tied to running a production service that tends to be manual, repetitive, automatable, tactical, devoid of enduring value, and that scales linearly as a service grows. https://landing.google.com/sre/sre-book/chapters/eliminating-toil/
Strategies（SRE Workbook の教え） • Promote Toil Reduction as a Feature • Start Small and Then Improve • Increase Uniformity • Assess Risk Within Automation • Automate Toil Response • Use Open Source and Third-Party Tools • Use Feedback to Improve • Identify and Measure Toil • Engineer Toil Out of the System • Reject the Toil • Use SLOs to Reduce Toil • Start with Human-Backed Interfaces • Provide Self-Service Methods • Get Support from Management and Colleagues https://landing.google.com/sre/workbook/chapters/eliminating-toil/
Matt の DevOps 定義 DevOps is the practice of developers being responsible for operating their services in production, 24/7. This includes development using shared infrastructure primitives, testing, on-call, reliability engineering, disaster recovery, defining SLOs, monitoring setup and alarming, debugging and performance analysis, incident root cause analysis, provisioning and deployment, etc. The human scalability of “DevOps” https://medium.com/@mattklein123/the-human-scalability-of-devops-e36c37d3db6a
you build” puts the devops principles in action by having the team that develops a system also be responsible for operating and supporting that system. Distributing this responsibility to each development team, rather than externalizing it, creates direct feedback loops and aligns incentives. Teams that feel operational pain are empowered to remediate the pain by changing their system design or code; they are responsible and accountable for both functions. Full Cycle Developers at Netflix — Operate What You Build https://medium.com/netflix-techblog/full-cycle-developers-at-netflix-a08c31f83249 Full Cycle Developer @ Netflix
Reporting による新着バグ検知 > Stackdriver Error Reporting allows you to monitor your application’s errors, aggregated into meaningful groups tailored to your programming language and framework. This helps you see the problems rather than the noise. Monitor your application errors with Stackdriver Error Reporting https://cloud.google.com/blog/products/gcp/monitor-your-application-errors-with-stackdriver-error-reporting
Don’t Want DevOps. I Want NoOps. https://go.forrester.com/blogs/11-02-07-i_dont_want_devops_i_want_noops/ Augment DevOps With NoOps https://www.forrester.com/report/Augment+DevOps+With+NoOps/-/E-RES59203?objectid=RES59203 jallspaw/gist:2140086 https://gist.github.com/jallspaw/2140086 Ops, DevOps and PaaS (NoOps) at Netflix http://perfcap.blogspot.com/2012/03/ops-devops-and-noops-at-netflix.html NoOps != No Operations https://www.slideshare.net/dtzar/noops-no-operations?qid=0ed06484-5b59-447b-a23b-bb77afd55d95&v=&b=&from_search=40 NoOps: Its Meaning and the Debate around It https://www.infoq.com/news/2012/03/NoOps/ Does the Future of DevOps Lie in NoOps? https://devops.com/future-devops-lie-noops/