Reposted from: ‘Not My Problem’: A Big Problem for DevOps Teams – DevOps.com
Not my problem (NMP) — (n)
1. a statement, or position, of apathy expressed by those who perceive they are external and unaffected by a negative predicament. While sometimes warranted, it is typically uttered by those who perceive themselves as powerless; can’t be bothered; are too lazy, or are selfish non-contributing leeches. See also “complete cop out.”
2. an attitude that will stymie attempts to implement DevOps in your organization and will thwart success
3. (archaic) Actually not your problem
While perhaps it’s become more frequent in our culture of relative indifference, some of our oldest stories bear witness to how timeless the phenomenon “not my problem” is. For example, in the biblical story of Cain murdering Abel, God asks Cain afterward, “Hey Cain, I can’t find Able. Do you know where he is?” Cain responds famously, “Am I my brother’s keeper? (NMP)” It crosses country borders and language barriers, too: A transliteration of the same sentiment in Polish is, “Not my circus, not my monkeys.”
Continue reading ‘Not My Problem’: A Big Problem for DevOps Teams
(Reblogged from A comment left on Slashdot. – Development Chaos Theory)
The problem is that our industry, unlike every other single industry except acting and modeling (and note neither are known for “intelligence”) worship at the altar of youth. I don’t know the number of people I’ve encountered who tell me that by being older, my experience is worthless since all the stuff I’ve learned has become obsolete.
This, despite the fact that the dominant operating systems used in most systems is based on an operating system that is nearly 50 years old, the “new” features being added to many “modern” languages are really concepts from languages that are between 50 and 60 years old or older, and most of the concepts we bandy about as cutting edge were developed from 20 to 50 years ago.
It also doesn’t help that the youth whose accomplishments we worship usually get concepts wrong. I don’t know the number of times I’ve seen someone claim code was refactored along some new-fangled “improvement” over an “outdated” design pattern who wrote objects that bare no resemblance to the pattern they claim to be following. (In the case above, the classes they used included “modules” and “models”, neither which are part of the VIPER backronym.) And when I indicate that the “massive view controller” problem often represents a misunderstanding as to what constitutes a model and what constitutes a view, I’m told that I have no idea what I’m talking about–despite having more experience than the critic has been alive, and despite graduating from Caltech–meaning I’m probably not a complete idiot.)
Continue reading A comment left on Slashdot. – Development Chaos Theory
This is a repost. This is an excellent list of all the operation areas that need to be well managed. The theme is: with automation, templates, and monitoring. Not with manual fiddling until it works. See below, for the link to the full post.
Structured system management is a concept that covers the fundamentals of building, securing, deploying, monitoring, logging, alerting, and documenting networks, servers and applications. Structured system management implies that you have those fundamentals in place, you execute them consistently, and you know all cases where you are inconsistent. The converse of structured system management is what I call ad hoc system management, where every system has it own plan, undocumented and inconsistent, and you don’t know how inconsistent they are, because you’ve never looked.
You know you have structured system management when:
- You manage with scripts, not mouse clicks.
- You manage consistently across platforms.
- You deploy servers from images, not install DVD’s.
- You can re-install a server and its applications from your documentation.
- You install and configure to the least bit principle (WebCite) for all your devices, servers, operating systems and applications.
- You have full remote management of all your servers and devices.
- You build router, switch and firewall configurations from templates, not from scratch.
- You have version control and auditing on critical system and application configuration files.
- You automatically monitor, strip chart and alert on at least memory, network and disk I/O, and CPU.
- You automatically monitor, strip chart and alert on application response time and availability.
- You have a structure and process for your documentation
- You have change management and change auditing sufficient to determine who/what/when/why on any change to any system or application critical file.
- You have a patch strategy,
- You have neat cabling and racks.
- You determine root cause of failures, outages and performance slowdowns
- You have centralized logging, alerting, log rotation and basic log analysis tools.
- You have installed, configured and are actually using your vendor provided platform management software.
- You keep it simple
For details see the blog: Ad Hoc Verses Structured System Management (WebCite)
Subject: Your Call Water Series - Feedback
This is in response to: “Your Call Water Series” [webcitation] radio program on KALW, 91.7 in San Francisco.
I’ve listened a few of your programs on water. There have been mentions about learning from other communities and countries. Most of the focus seems to be on “big solutions,” but water cycles happen at global, regional, and local levels. We need solutions that address the problems at all these different levels.
Of course, there is a need for large water projects, to move water to large cities. But the large projects will not solve the water problem if the “small water cycles” are not addressed. Those cycles need to be addressed at more local levels. For example, water-retention landscaping methods can revitalize areas where the water and land have been abused.
Ground water depletion is talked about as if groundwater is a limited resource. In some ways it is, but it’s not the sort of resource one can hoard. “Mainstream” water management attempts to limit reservoir evaporation and seepage into the ground as if those things were bad. That is backward. Water needs to evaporate, so it can return as rain. Water needs to seep into the ground so that it can feed life and be purified by life and the ground. In contrast, water retention landscaping techniques use small reservoirs in order to slow down water runoff, so that water has time to seep into the ground.
From what I’ve heard about the California Ground Water Law, the focus is on limiting groundwater use, i.e. limiting the amount of water being removed. Words like “sustainable” are used, but there is almost nothing said about practices that get more water back into the ground. Not only are we taking out water faster than it is going back in, we are prioritizing practices designed to prevent water from going back into the ground. By focusing only on limiting water extraction, only half the problem is being addressed.
Continue reading Your Call Water Series – Feedback