PracOps - Revision history

Robert Brockway at 04:27, 13 April 2024

2024-04-13T04:27:27Z

← Older revision		Revision as of 04:27, 13 April 2024
Line 1:		Line 1:
	[[PracOps]] is a technical philosophy developed by [[Robert Brockway]]. The philosophy focuses on the use of [[free and open source software]] and aims to keep systems as simple possible while still achieving their operational objectives reliably. PracOps argues that humans should be able to fully understand the functioning of a system.		[[PracOps]] is a technical philosophy developed by [[Robert Brockway]].

	== Backups ==		== Backups ==
Line 10:		Line 10:

	== Comprehension ==		== Comprehension ==

			Humans should be able to fully understand the functioning of a system.

	== Consistency ==		== Consistency ==
Line 46:		Line 48:

	== Simplicity ==		== Simplicity ==

			As simple as possible while still achieving their operational objectives reliably.

	{{Draft}}		{{Draft}}

Robert Brockway: /* Purpose */

2024-04-13T03:15:49Z

Purpose

← Older revision		Revision as of 03:15, 13 April 2024
Line 31:		Line 31:
	== Purpose ==		== Purpose ==

	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.		An organisation should implement a solution which meets their needs and is fit for purpose. 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.

	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.		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.

Robert Brockway: /* Licencing */

2024-04-13T03:15:29Z

Licencing

← Older revision		Revision as of 03:15, 13 April 2024
Line 23:		Line 23:
	== Licencing ==		== Licencing ==

	Use [[FOSS]] whenever it is practical to do so. Non-FOSS can be used when no reasonable FOSS solution exists.		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 ==		== Monitoring ==

Robert Brockway at 03:14, 13 April 2024

2024-04-13T03:14:37Z

← Older revision		Revision as of 03:14, 13 April 2024
Line 14:		Line 14:

	Environments should be as consistent as feasible. Avoid exceptions where feasible.		Environments should be as consistent as feasible. Avoid exceptions where feasible.

			== Hosting ==

			Both self-hosted and outsourced solutions should be considered. Many organisations today have a policy to only outsource. As a result solutions are outsourced even when cheaper and more reliable self-hosts solutions exist.

			For decades IT has swung between insourcing and outsourcing. Since approximately 2014 IT has been experiencing extreme outsourcing even when it is counterproductive.

	== Licencing ==		== Licencing ==

Robert Brockway at 03:11, 13 April 2024

2024-04-13T03:11:17Z

← Older revision		Revision as of 03:11, 13 April 2024
Line 15:		Line 15:
	Environments should be as consistent as feasible. Avoid exceptions where feasible.		Environments should be as consistent as feasible. Avoid exceptions where feasible.

	== ~~FOSS~~ ==		== Licencing ==

			Use [[FOSS]] whenever it is practical to do so. Non-FOSS can be used when no reasonable FOSS solution exists.

	== Monitoring ==		== Monitoring ==

Robert Brockway at 03:10, 13 April 2024

2024-04-13T03:10:09Z

← Older revision		Revision as of 03:10, 13 April 2024
Line 14:		Line 14:

	Environments should be as consistent as feasible. Avoid exceptions where feasible.		Environments should be as consistent as feasible. Avoid exceptions where feasible.

	== Purpose ==

⚫	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.

⚫	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.

	== FOSS ==		== FOSS ==
Line 27:		Line 21:
	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.		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.

	== ~~Simplicity~~ ==		== Purpose ==

		⚫	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.

		⚫	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.

	== Reliability ==		== Reliability ==
Line 38:		Line 36:

	Data from the Uptime Institute clearly shows that outages are getting longer.		Data from the Uptime Institute clearly shows that outages are getting longer.

			== Simplicity ==

	{{Draft}}		{{Draft}}

Robert Brockway at 03:09, 13 April 2024

2024-04-13T03:09:29Z

← Older revision		Revision as of 03:09, 13 April 2024
Line 11:		Line 11:
	== Comprehension ==		== Comprehension ==

	== ~~Fit For Purpose~~ ==		== Consistency ==

			Environments should be as consistent as feasible. Avoid exceptions where feasible.

			== Purpose ==

	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.		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.

Robert Brockway at 02:12, 13 April 2024

2024-04-13T02:12:19Z

← Older revision		Revision as of 02:12, 13 April 2024
Line 10:		Line 10:

	== Comprehension ==		== Comprehension ==

			== Fit For Purpose ==

			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.

			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.

	== FOSS ==		== FOSS ==

Robert Brockway at 02:08, 13 April 2024

2024-04-13T02:08:17Z

← Older revision		Revision as of 02:08, 13 April 2024
Line 8:		Line 8:

	There is such a thing as feature completeness.		There is such a thing as feature completeness.

			== Comprehension ==

	== FOSS ==		== FOSS ==
Line 20:		Line 22:

	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.		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.

			Pracops argues that computers are ultimately tools. Tools that require excessive maintenance to work are not good tools.

			People expect their car to start on demand but apparently accept far more failures from general computer systems.

			Data from the Uptime Institute clearly shows that outages are getting longer.

	{{Draft}}		{{Draft}}

Robert Brockway at 02:05, 13 April 2024

2024-04-13T02:05:19Z

← Older revision		Revision as of 02:05, 13 April 2024
Line 1:		Line 1:
	[[PracOps]] is a technical philosophy developed by [[Robert Brockway]]. The philosophy focuses on the use of [[free and open source software]] and ~~simplicity~~.		[[PracOps]] is a technical philosophy developed by [[Robert Brockway]]. The philosophy focuses on the use of [[free and open source software]] and aims to keep systems as simple possible while still achieving their operational objectives reliably. PracOps argues that humans should be able to fully understand the functioning of a system.

			== Backups ==

			== Change ==

			Change of the sake of change is bad.

			There is such a thing as feature completeness.

			== FOSS ==

			== Monitoring ==

			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.

			== Simplicity ==

			== Reliability ==

			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.

			{{Draft}}
	{{PracOps}}		{{PracOps}}