Why is this solely for JIRA? This should be generic.
For example, it might be necessary to bring down Talk, ID dashboard, Confluence, Atlas, or Bamboo – the downtime is (usually) minimized and procedures will need to be generic.
My question is why is this being written by you and not those on the infrastructure team? The whole document needs to have far more detail you put in there. Why is somebody with very little to no Ops experience writing things like this? When writing standard operating procedures for devops stuff, you need to go into detail. It needs to be generic.
So @chagara made this document originally on google drive, and I migrated it to our wiki (as all the other documents). I’ve been making a huge effort to get more and more information to the wiki.
This is one document we didn’t make completely public because it only handles the internals of the tools we use. I’m particularly not sure what there is to comment there, because we are talking about how to setup status.io and team calendars. If there’s any information that should be public, I’d kindly ask to create a page in https://wiki.openmrs.org/display/ISM/Home, but it would be nice to ask first if no one has any security concern before that.
As I said after migrating the documents, please feel free to add trusted person to be able to read our wiki! That was the main reason why I migrated all the docs from google drive, to give more visibility.
Again, we are not sure why one of our documents is being asked to be reviewed. When there’s something wrong with one document, we just alert on telegram and edit it straightaway.
What exactly are we trying to achieve with this discussion? What is the problem we are trying to solve?
Thanks for all the feedback. I didn’t create this document and I don’t entirely understand it which is why I came to you guys. I’m also struggling to find anything on the wiki that would resemble a document like this.
This document is to be used as an official SOP for OpenMRS, which I have yet to find in a similar format. So if the steps and procedures are agreed on with this document, I will use them for the official OpenMRS SOP.
@cintiadr, I followed that github link to a 404 page… is that just me?
@jeffneiman, it’s a private repository which cannot be made public unless the history is scrubbed (contains sensitive information which could compromise system security). @burke and @darius have access to the wiki.
@jeffneiman, I still don’t undestand which problem are we trying to to solve. With that understanding, it’s much easier to give you more comments and a solution.
What is an ‘official OpenMRS SOP’? Who would be the target audience of this document?
If it’s only the ITSM team, I suppose there’s no reason to make it somehow any more ‘official’ than it already is, because we are only writing documents to help yourselves, and we are always changing them or improving them
While there’s quite a few guides, they have been so far maintained by us only (as we are the ones actually using them). They are not official, they are simply useful.
It’s not like we will have someone who is not part of infra team and is not actively talking to us will schedule an outage. I doubt that knowing where to click in status.io or pingdom UI is relevant to a lot of people, but clearly some other bits might be missing.
Nobody outside of the infrastructure team should have access to production or staging servers. Staging servers are to be treated like production servers. Outages pertain to production servers(staging servers are for us to test), nobody outside of the team will be making the decision to schedule service outages – it doesn’t need to be official and should be authored by those on the infrastructure team.
I’m with @cintiadr on this. It confuses me and smells like micromanagement.
We run on the Principle of Least Privilege. Nobody needs access to production servers. Nobody should be on them when they don’t need to be. That’s how typical devops works actually.
I’m with him on this. Things haven’t changed at all. One of the reasons I left was because this is treated like a business…we’re not “personnel” – we’re volunteers…unpaid volunteers. I’m offended by this level of bull.
Has nobody noticed that there was an exodus, with me lasting the longest before I got fed up? This entire thread is indicative of this.
Sure. The wiki is a git repository, every /dev/5 has access and can make a clone. If you don’t trust github backups, you can setup a cron task somewhere. There’s even all the backup strategy guide too, so pretty sure it can be included there. I don’t think it’s particularly bad to have other backups, that is actually pretty sane.
But we’ll follow any process which will make sense to us and the community, regardless of any kind of external approve.