Poor user experience - or DevOps and definitely no SRE.

 In my continuation to find examples of where software systems have not moved beyond the SDLC of the 1980s and 90s, or have started doing DevOps, but haven't realised that now we're in to SRE, and if you think SRE is DevOps, then there's a problem.

DevOps = Automation, implement the new features, make sure it's reliable and stable, make sure "we" can fix an issue when it occurs.

Right, you probably think that includes SRE because you're thinking about the client/stakeholder, but how do they (the client) know if the problem is them or you?

So many organisations don't provide enough information to a client when they have an issue, either through an update, or an outage of some kind.

SRE requires our understanding of the user, not just in how they use the application, but making sure they don't have to be technical. It's not down to the user to uninstall and re-install the application and then have to log back in - that to a non-technical user is the biggest "bug bear" you could ask them to do. We're now in the 21st century and if you're a large organisation with lots of clients, should be able to think more about your customers experience. Yes, SRE has some nice principles for determining whether the user is experiencing a degradation in performance, or whether developers should be focusing on reliability rather than new features. BUT we should still be thinking, are we putting too much on the end user and assuming that they are comfortable in re-installing, or want keep putting in their password every week?

These are areas that we should be thinking about if we want to make our software more exceptional than the competition. If you can provide the experience to users that saves them logging in every 5 minutes, or having to re-install manually, then you're moving into a whole new area of customer satisfaction.

Today's poor practice;

Southern Water's application that 1000s of sea and river swimmers rely on at this time of year due to the amount of sewage discharges they do, even in non-extreme weather conditions is out for the entire day - see the picture attached.

https://riversandseaswatch.southernwater.co.uk/release-history?BathingSite=FOLKESTONE&Status=Genuine

Yesterday Tennis TV had performed an update without checking the client applications, causing the App to just quit with no warning messages - this in turn causing the user to become frustrated and panic.

Don't slip back to the 1970 and 1980s method of customer support and hide behind the Internet and ChatBots (in the 70s and 80s it was the phone), and not provide adequate information to the users. Today there are many practices and tooling that we should not be seeing this type of service as users.

Step in to the 21st century and start using DevOps environments to test your updates and upgrades for both application and infrastructure before deploying to LIVE. Ensure that your pre-Live environments have at least 1 of every resource so that there is NOTHING NEW when you deploy to LIVE.

TESTING is not a last minute options, it's a before you code to ensure you met requirements, and that you don't write code to suit the tests (1980s and 90s).

Provide meaningful error messages to your users, don't fail SILENT!

Lost photos and videos

A friend of mine was migrating his Emby system to a new all singing all dancing server that he built with Unraid, since that was what he was using originally.

During his migration to the new server and setting up the new disks with Emby, all of the photos and videos disappeared from one of the disks, leaving him with lots of photos and videos being lost.

Luckily before doing anything drastic he called me and asked if I'd come over to take a look.  So I did.

Conveniently he hadn't used his largest disk, meaning we could do a recovery, and being Linux based file systems meant this was easy to do, but would take a long while to perform the recovery.

Unraid was running from USB stick in memory.  This meant that for each recovery run the software would need to be installed again; minor issue.

The main element for helping out was to provide my friend with the knowledge to be able to do this himself.  So showing him how to;

1. Identify the Linux disk name from Unraid, where Unraid calls them Disk 1, Disk 2, etc, but clicking the disk provides the information for the /dev location - which I told him he needed to perform the recovery.

2. Install the software on Unraid, as he would need to do this for each recovery.

3. Perform the recovery.

4. Sift through 1000s of files as they may not have the correct name after recovery, especially if the directory information is unavailable.

Having found the relevant disk name for the data that had disappeared, I then stopped Unraid to free up the disks to mount using the normal Linux commands, and ensure no other processes were affecting the disks.

2 disks were required for the task.

• The disk with the missing data
• The disk that would be the recovery location

The recovery location disk was mounted to /mnt/recovery.

The application to perform the recovery is called testdisk which contains 2 methods of recovery. The more advanced testdisk command and the easier photorec command.  I opted for photorec since it did most of the grunt work for you, leaving you to supply the disk to recover and the location to recover too.  TestDisk requires more information and knowledge of the file systems you were recovering.

Having supplied photorec with the device path of the disk to recover (unmounted) and the location to recover to (mounted drive : /mnt/recovery), it went off and started the recover, and within seconds had discovered several hundred photos and videos, stating a recovery time of 24 hours, which changed as it worked through the disk.

After a day or 2 the task completed and my friend informed me that he had to sift through the 1000s of files, some of which he had no idea they were on there, and others being the files he needed.  This he was working through for quite a few days.  He has the other 4 disks to work through.