I'm Shaun Norris.
I run cloud infrastructure services
at Standard Chartered Bank in Singapore.
We've been around for almost 165 years,
so we predate things like electric lights
and electricity, and definitely things like DevOps and cloud.
We had about $14 billion in revenue in US dollars
last year.
We operate in over 60 countries, more than nine
million individual customers.
We've got more than 1,000 applications in production.
All the blue-shaded areas you can see on this map
are areas where we operate as a bank.
Each of these countries have their own financial regulators,
their own views on things like data sovereignty,
and cloud governance.
Those 63 or so countries that we're in,
with regulations, we also have obviously a lot
of internal compliance and policy.
Our processes over time have grown organically
to be optimized for compliance, and not speed.
Servers still take weeks to provision in our environment.
While parts of the delivery chain are automated,
a lot of it remains manual.
We have this idea of a break glass mechanism for production.
That if you want to do an operation in production,
say there's a production incident going on
and you need to SSH into a Linux server
to maybe do some troubleshooting and remediation,
you have to go through and unvault a privilege password,
that you log who you are, what incident ticket you are.
You go in and do your work, and you save it in the change requests,
and you revault the password.
As if that wasn't enough, in order
to make sure that you only did the things
you were supposed to do with that privileged password,
we have an extra component.
Where we like this idea of maker checker.
In production, if doing a change then you
need to have your manager kind of sign off.
So what that means in practicality
is that after this change request is done, and checked
back in, your manager then has to watch
a video of your entire screen session,
and then attest and sign off that you did the things you
were supposed to do, and you didn't do any of things
you weren't supposed to do. Effectively,
at least doubling the amount of resource effort
that goes into production changes.
You might not be surprised that this process,
and this way of working, is sometimes prone to delay.
We've got recognition at all levels of our organization
that we need to change the way we do technology.
A junior engineer, about two years ago in the bank,
said I've heard of this thing called Rundeck
and I think we should start using it.
So it was an unfunded project, and he really
had no budget to do it.
He didn't really have the organizational position
to get it done.
But he just kept at it, and he kind of
got it through the bureaucracy to get it installed as a PoC.
And they started using it, for things like service restarts
and some fail over type activities.
Well, when I came in and started running the retail team,
I said well, we need some of this.
We've now gotten to the point where
we've run hundreds of thousands of Rundeck jobs.
Really interesting from this because we're
using it for specific incident remediation.
Say there's a service restart.
Well, rather than having to go in and unvault a password,
and do that whole video watching story
that I told you about earlier, now because it's constrained,
and inversion control, and can be audited,
we can pass that requirement because it's kind
of a chain of custody thing.
You know exactly what the scripts going to do every time. And you
can tell it's provenance, et cetera.
And so we've found TTR reduces by on average 25 minutes
for apps where we're using Rundeck versus where we don't.
That's really exciting.
We think next year, Rundeck is probably
going to save us about 28 people years worth of work, at fairly
conservative estimates.
And we haven't even rolled it out particularly widely, yet.
This has been a huge win for us.
I'd be happy to talk to anybody, if you want
to find out more about that.
Our journey is really just getting started.
It has no finish line in it, and it is going to continue.
So I really like this as a metaphor
for continuous improvement and continuous learning.
Thank you very much.