A vessel traffic system depends on a lot of separate parts working together. Radar, AIS receivers, processing services, and the operator interface all have to agree on what is happening. My job at Tidalis is to help make that happen.

Kwai Tsing Container Terminal with cargo cranes and ships in the harbour
Kwai Tsing Container Terminal, Hong Kong. Context photo, not a client deployment. ystsoi · CC BY 2.0 · resized.
Role
Test & Integration Engineer at Tidalis
Since
December 2024
Systems
Linux, AWS, Kubernetes, Rancher
Day-to-day tools
Grafana, scripting, logs, Jira
Radar and AIS inputs feed processing services and operator visualization, supported by monitoring, patch verification and staged rollout.
A simplified view of my integration responsibilities, rather than a client system diagram.

Connecting the pieces

I work on deployments of MaritimeControl, a Linux-based Vessel Traffic Service platform, and its cloud-native Service Suite Edition. The work spans sensor ingestion, processing, and visualization.

On the Linux side, that includes integrating components such as radar, AIS, and SCADA. On the cloud side, I’ve deployed and customized services on AWS and managed Kubernetes clusters through Rancher.

I work with the product teams and vendors behind these components. I don’t build the whole platform myself; my responsibility is in deployment, integration, testing, and support.

Making the system easier to support

I build Grafana dashboards for system health and vessel traffic metrics, as well as automated maintenance and health-check pipelines. These are part of the day-to-day work of keeping a deployed system understandable and maintainable.

I also take part in rotating on-call support. That includes remote troubleshooting and, when needed, on-site work during support weeks.

How a fix reaches production

  1. Start with the evidence. Gather the symptoms and logs, including crash and segfault information, and record the issue in Jira.
  2. Work through the cause. Coordinate with the relevant product team or vendor and track the investigation through to a proposed fix.
  3. Test it first. Verify the patch in a test environment before it reaches a live system.
  4. Roll out in stages. Deploy to one production node, validate the behaviour, and then promote the patch to the remaining nodes.

What I bring to software projects

This work has made production behaviour a normal part of how I think about software. I spend time on logs, monitoring, component boundaries, and how to verify a change, alongside the change itself.

It is also collaborative work. A useful bug report and a clear handover can matter just as much as finding the faulty component. I carry that approach into my own applications and trading systems.

This overview describes my responsibilities and general working process. Client configurations, internal incident details, and proprietary implementation details are not included.