PracOps: Difference between revisions
Ollama: improve existing draft article |
|||
| (2 intermediate revisions by one other user not shown) | |||
| Line 1: | Line 1: | ||
[[PracOps]] is a technical philosophy developed by [[Robert Brockway]]. |
[[PracOps]] is a technical philosophy developed by [[Robert Brockway]]. It emphasizes practical, sustainable approaches to system design and management, focusing on reliability, simplicity, and alignment with organizational needs. The philosophy addresses challenges in modern IT practices, advocating for principles that balance innovation with operational stability. |
||
{{H2|Core Principles}} |
|||
== Backups == |
|||
{{H2|Change}} |
|||
Change for the sake of change is detrimental. While adaptability is essential, it should be driven by clear objectives rather than arbitrary updates. The philosophy emphasizes achieving feature completeness—ensuring systems meet functional requirements without unnecessary complexity or premature obsolescence. |
|||
Change of the sake of change is bad. |
|||
| ⚫ | |||
There is such a thing as feature completeness. |
|||
A system's design should prioritize human understanding. Users and operators must be able to fully grasp its functioning to ensure effective maintenance, troubleshooting, and long-term sustainability. This principle challenges the trend of opaque, vendor-locked solutions that obscure operational details. |
|||
| ⚫ | |||
{{H2|Consistency}} |
|||
Environments should maintain as much consistency as feasible. Exceptions should be avoided unless absolutely necessary. Consistency reduces the risk of errors, simplifies training, and enhances the reliability of workflows across development, testing, and production stages. |
|||
Environments should be as consistent as feasible. Avoid exceptions where feasible. |
|||
{{H2|Hosting}} |
|||
Both self-hosted and outsourced solutions should be |
Both self-hosted and outsourced solutions should be evaluated based on their merits. However, many organizations have adopted policies favoring outsourcing, even when self-hosted alternatives are more cost-effective or reliable. This trend, which intensified around 2014, has led to suboptimal decisions in some cases, prioritizing vendor relationships over practicality. |
||
{{H2|Licensing}} |
|||
For decades IT has swung between insourcing and outsourcing. Since approximately 2014 IT has been experiencing extreme outsourcing even when it is counterproductive. |
|||
[[FOSS]] (Free and Open Source Software) should be used whenever feasible, as it promotes transparency, flexibility, and long-term sustainability. Non-FOSS solutions may be acceptable only when no viable FOSS alternatives exist, whether for insourced or outsourced systems. |
|||
== Licencing == |
|||
| ⚫ | |||
Use [[FOSS]] whenever it is practical to do so. Non-FOSS can be used when no reasonable FOSS solution exists. This is true for both insourcing and outsourcing. |
|||
Monitoring should define the boundaries of a system's expected behavior rather than merely detecting isolated failures. When configured correctly, monitoring tools alert operators when system performance deviates from predefined limits—static or dynamic—ensuring early intervention and preventing cascading failures. |
|||
| ⚫ | |||
| ⚫ | |||
The purpose of monitoring is to describe the bonunds of the running system, not merely to detect specific failure more. Properly configured a monitor will alert when the behaviour of the system moves outside the pre-defined limits. These limits could be statically or dynamically assigned. |
|||
Organizations should implement solutions tailored to their specific needs rather than imitating larger entities. Many systems are unnecessarily complex and expensive due to a lack of alignment with actual requirements. For example, government services often over-provision capacity beyond the maximum plausible demand, leading to wasted resources. |
|||
| ⚫ | |||
| ⚫ | |||
An organisation should implement a solution which meets their needs. Too many organisations just do what other, often larger, organisations do. As a result many computer systems are much more expensive, complex and unreliable than they need to be. |
|||
Unscheduled outages should be minimized. Since 2010, there has been a troubling trend of normalizing system failures, with users becoming accustomed to subpar reliability. [[PracOps]] argues that computers are tools meant to function without excessive maintenance. The [[Uptime Institute]] has documented a rise in outage durations, underscoring the need for more robust reliability standards. |
|||
Many organisations can estimate maximum loads. Eg, in general a government department providing a service in a jurisdiction knows that the maximum number of people who can use their service is the number of people who reside in the jurisdiction. Provisioning a service which can scale far past this, or even only becomes economical at scales beyond the size of the jurisdiction is suboptimal. |
|||
| ⚫ | |||
| ⚫ | |||
Simplicity should be prioritized without compromising operational objectives. Systems should be as straightforward as possible while maintaining reliability and meeting functional requirements. This principle counters the tendency to over-engineer solutions, which often leads to increased complexity and maintenance burdens. |
|||
Unscheduled outages should be minimised. A concerning trend in IT since 2010 is to acclimate users to outages and failures. Users should expect more of the computer systems they use. |
|||
{{H2|References}} |
|||
Pracops argues that computers are ultimately tools. Tools that require excessive maintenance to work are not good tools. |
|||
* [[Uptime Institute]] |
|||
People expect their car to start on demand but apparently accept far more failures from general computer systems. |
|||
{{Ollama}} |
|||
Data from the Uptime Institute clearly shows that outages are getting longer. |
|||
{{Pending Human Review}} |
|||
| ⚫ | |||
{{Draft}} |
|||
{{PracOps}} |
|||
Latest revision as of 11:14, 3 November 2026
PracOps is a technical philosophy developed by Robert Brockway. It emphasizes practical, sustainable approaches to system design and management, focusing on reliability, simplicity, and alignment with organizational needs. The philosophy addresses challenges in modern IT practices, advocating for principles that balance innovation with operational stability.
Core Principles
Change
Change for the sake of change is detrimental. While adaptability is essential, it should be driven by clear objectives rather than arbitrary updates. The philosophy emphasizes achieving feature completeness—ensuring systems meet functional requirements without unnecessary complexity or premature obsolescence.
Comprehension
A system's design should prioritize human understanding. Users and operators must be able to fully grasp its functioning to ensure effective maintenance, troubleshooting, and long-term sustainability. This principle challenges the trend of opaque, vendor-locked solutions that obscure operational details.
Consistency
Environments should maintain as much consistency as feasible. Exceptions should be avoided unless absolutely necessary. Consistency reduces the risk of errors, simplifies training, and enhances the reliability of workflows across development, testing, and production stages.
Hosting
Both self-hosted and outsourced solutions should be evaluated based on their merits. However, many organizations have adopted policies favoring outsourcing, even when self-hosted alternatives are more cost-effective or reliable. This trend, which intensified around 2014, has led to suboptimal decisions in some cases, prioritizing vendor relationships over practicality.
Licensing
FOSS (Free and Open Source Software) should be used whenever feasible, as it promotes transparency, flexibility, and long-term sustainability. Non-FOSS solutions may be acceptable only when no viable FOSS alternatives exist, whether for insourced or outsourced systems.
Monitoring
Monitoring should define the boundaries of a system's expected behavior rather than merely detecting isolated failures. When configured correctly, monitoring tools alert operators when system performance deviates from predefined limits—static or dynamic—ensuring early intervention and preventing cascading failures.
Purpose
Organizations should implement solutions tailored to their specific needs rather than imitating larger entities. Many systems are unnecessarily complex and expensive due to a lack of alignment with actual requirements. For example, government services often over-provision capacity beyond the maximum plausible demand, leading to wasted resources.
Reliability
Unscheduled outages should be minimized. Since 2010, there has been a troubling trend of normalizing system failures, with users becoming accustomed to subpar reliability. PracOps argues that computers are tools meant to function without excessive maintenance. The Uptime Institute has documented a rise in outage durations, underscoring the need for more robust reliability standards.
Simplicity
Simplicity should be prioritized without compromising operational objectives. Systems should be as straightforward as possible while maintaining reliability and meeting functional requirements. This principle counters the tendency to over-engineer solutions, which often leads to increased complexity and maintenance burdens.
References
This page contains information generated by Ollama. The information was reviewed, and may have been altered, by a human editor before being added to the Featured category. As of July 2026 information generated by AI is not subject to copyright and is thus in the public domain. This page is pending human review.