I see many of you have privileges to access this document already, but I could use some extra eyes on this to make sure every part of the procedure is still relevant.
Can you please review this Scheduled Outage SOP for me and comment/correct the steps that might need to be corrected?
If everything looks good, please give it an approval!
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.
I could swear those documents were all migrated out of google docs, because visibility was pretty bad.
I checked in our wiki, the same document appears to be there.
I didnāt review it when migrating from google docs, is there anything specific that it was changed since the migration?
This doc is more or less not even needed. This isnāt something the public at large needs. Just in case, @chagaraās message wasnāt clear ā that is what he was saying. Procedures are already in place.
@chagara, I think youāre saying that there is already a document (on the wiki) that describes our actual SOPs. Can you share a pointer to it here for Jeff?
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, youād need an account in github so any of us could grant you access (I couldnāt find your github account in your profile, so I couldnāt grant you access).
@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.
Guys, weāve gone well beyond the scope of my question and weāre making assumptions based on nothing.
If this āprocessā is accurate, we will have the @Leadership team review it for approval and securely file it away for any potential future reference, which the appropriate personnel will be handling.
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.