Sure, automation could make sense. Especially if needed daily. But there could be one-offs, or it make take time to automate. Until then, and perhaps beyond, 2 fundamental things happen in Ops - read of state and write to state. Reading requires a human in the loop to ascertain validity. Writing, should be followed up with a read. Refer to the former.

This is for your own security, ease in record keeping, and control. Having all customer's data in a central location endangers all customers in the event of a single hack.

Any document is fine; even a PDF. However, text is best and encouraged, as it can most easily be copied and pasted into a command line if it includes commands. We will reject your runbook with advice if it's not written well enough per work and scheduling required.

We're based in Tokyo. When your Ops finish work, we start. A healthy company requires healthy staff getting regular nightly sleep. Tired staff are likely to make execution errors and have flawed thinking while resolving potential issues.

There's enough of a time overlap to have meetings. And we encourage you to do so any day.

Please refer to this article.

We're not going to give the usual meaningless line of how we take your security seriously. Instead, and more meaningfully, we'll explain what is done.

Runbooks, schedules, and secrets (i.e. entryption keys, certificates, passwords, etc.) can and certainly secrets should be kept in the GPG-encrypted directory of your bare Git repository hosted on one of your own server. The commits of which signed automatically using your GPG keys, so we can authenticate commits.

This same Git host server above could also be used as an execution hop into target operations.

All Git and SSH connections are done without Agent and X11 forwarding.

We also use Purism's Librem laptop line, each with an exclusive hardware router, and Purism's Pureboot process with their Librem key to ensure the laptops firware, system kernel, and boot process haven't been hacked with a root kit.

If there's more you prefer, let's look into setting that up too.

Public can provide great value under certain business cases, some providers better for particular cases, and multi-cloud is usually the best approach. We are public cloud-agnostic, ready for multi-cloud needs, constantly researches the industry ourselves, and can advise accordingly.

A dry run is simply when steps within a runbook are taken without actual changes to the state of your operations, is an excellent way to see how our service works, and best to ensure runbooks are written well.

The Git repository has a calendars directory, in which iCalendar-formatted files are to be created by you, which have rubook execution schedules. Any app supporting iCalendar format can be used, and we find Khal to be an excellent command line tool for the iCalendar format.