DigitableCourses
Portal settings
Русский
Show me around

Local and account-free. No account, no sign-up: whatever you type into the tools stays in this browser's localStorage and never reaches a server.

Our own counter records page opens and finishes: the address leaves, plus one tenth-of-the-text figure. No cookies, no outside trackers, your IP is not stored, Do Not Track is honoured. How to check that

The portal's own repository is not published, so we do not call it open source. What is open:

Digit flang Agent gate tools-core IT Tools Chat digitwm blender-mcp Hugging Face Licences

The portal lives on donations, paid consultations and requested write-ups, and on Workbench sales.

Support Order a write-up Workbench

There are no plans to make the courses paid.

Career

SRE and platform engineering

Reliability and tooling for other teams: infrastructure as code, observability, on-call.

Roles and moves Self-assessment

Step 2 of 2 · SRE and platform engineering

Which level inside the role?

Where people go from here: Backend developer, Architect, Data and machine learning, Team lead, tech lead, engineering manager

Not sure — open the whole role card Pick another role

  1. Entry
  2. Core level
  3. Senior and beyond

Entry

Straight to the self-check

Compared with development, the subject changes: not the feature but the machine it runs on and the traces it leaves behind.

Do now

  • I take a service that has fallen over or gone slow apart layer by layer instead of rebooting itI get from it does not work to a specific place: DNS, a route, TLS, the load balancer.
  • I build my own image and make it smaller deliberatelyI can explain what every layer in the image is for.
  • I make the build and the deployment repeatable somewhere other than my laptopThe pipeline builds the project from scratch on a clean machine.
  • I put my scripts in the repository and send them to reviewThe script lives in a repository rather than in a chat thread.

Where next

Core level

Sideways out of the role

What this step asks of you

  • I live confidently in Linux with no graphical interfaceI can find what ate the disk and the processor without installing anything extra.
  • I take a network problem apart layer by layer, not by rebootingI can get from it does not work to a specific place: DNS, a route, TLS, the load balancer.
  • I build and run containers deliberatelyI understand how a container differs from a virtual machine and why my image weighs a gigabyte.
  • I build the pipeline for build and deploymentThe project has a repeatable build that can be run from somewhere other than my laptop.
  • I write code, not only configsMy scripts live in a repository, go through review and have tests.

Common mistakes

  • Fixing things by rebooting: the cause stays and comes back at the worst moment.
  • Collecting knowledge in your own head and your personal scripts: the team starts depending on you being there.
  • Treating configs as something other than code: with no review and no history a change takes production down silently.

What to learn

  1. Entry
  2. Core level
  3. Senior and beyond

Core level

Straight to the self-check

Internal customers appear: other teams use your platform, and their downtime is now yours as well.

Do now

  • I bring the environment back up from the repository and check that what came out is the sameNot a single step needs a click in a console.
  • I take the dashboard to the state where it shows what exactly brokeThe panel carries an investigation rather than guesswork.
  • I rehearse a deployment with no downtime and a rollbackA canary or blue-green release works here rather than being described in a wiki.
  • I change a secret on a live system through the ordinary procedureRotation goes through without a night window and without panic.

Where next

Senior and beyond

Sideways out of the role

What this step asks of you

  • I keep infrastructure in code, not in clicks in a consoleThe environment comes back up from the repository, and we have tested that.
  • I operate the orchestrator, not only write manifestsI understand why a pod will not start, and I can read the events of the cluster.
  • I build observability you can run an investigation withThe dashboard shows what broke, not only that something is red.
  • I deploy without downtime and can roll backA canary or blue-green release actually works here rather than being described in a wiki.
  • I do not keep secrets in the repository and I can change themRotating a secret is an ordinary operation, not a special operation.

Common mistakes

  • Setting alerts on everything in sight: the noise teaches people not to look at alerts at all.
  • Keeping infrastructure in clicks: recovery after a failure turns into archaeology.
  • Building the platform for yourself: the neighbouring teams walk around it and build their own.

What to learn

  1. Entry
  2. Core level
  3. Senior and beyond

Senior and beyond

Straight to the self-check

Who you argue with changes: not the system but the product — about how much failure we allow ourselves and what we pay for it.

Do now

  • I state the reliability target for the service together with the productThe level of availability is agreed and affects decisions about releases.
  • I describe the failure model of my system and test it with a drillI know what happens when the network splits, because we have tried it.
  • I go through the night-time pages and remove what causes themOn-call has got quieter, and the log of pages shows it.
  • I find the most expensive line in the bill and propose a trade-offI can name the price of the cut in units of reliability, not only in money.

Where next

Not another step — a fork

Sideways out of the role

What this step asks of you

  • I set the reliability targets together with the product and live by themThe service has an agreed level of availability, and it affects decisions about releases.
  • I design the system for the failures that are certain to happenI know the failure model of my system and what happens when the network splits.
  • I manage the cost of infrastructure as an engineering problemI can name what costs the most and propose a trade-off that does not lose reliability.
  • I build an on-call rota that does not burn people outNight-time pages get looked into and reduced rather than counted as normal for the profession.
  • I treat my platform as a product for internal customersThe platform has documentation, a feedback loop and a clear path for migration.

Common mistakes

  • Holding reliability up as a personal feat: heroism on call ends in burnout and people leaving.
  • Demanding no failures at any cost: the cost grows faster than the benefit, and the conversation with the product never happens.
  • Treating the platform as an end in itself: with no documentation and no feedback nobody uses it.

What to learn

IT Tools source · GPL-3.0 Digitable Chat source · GPL-2.0-or-later Legal documents