42 lines
4.1 KiB
YAML
42 lines
4.1 KiB
YAML
uuid:
|
|
- value: d7d864f9-d3b6-4682-8e86-8d1f7c6f774e
|
|
langcode:
|
|
- value: en
|
|
type:
|
|
- target_id: daily_email
|
|
target_type: node_type
|
|
target_uuid: 8bde1f2f-eef9-4f2d-ae9c-96921f8193d7
|
|
revision_timestamp:
|
|
- value: '2025-05-19T22:10:38+00:00'
|
|
revision_uid:
|
|
- target_type: user
|
|
target_uuid: b8966985-d4b2-42a7-a319-2e94ccfbb849
|
|
revision_log: { }
|
|
status:
|
|
- value: true
|
|
uid:
|
|
- target_type: user
|
|
target_uuid: b8966985-d4b2-42a7-a319-2e94ccfbb849
|
|
title:
|
|
- value: 'How quickly can you get back online?'
|
|
created:
|
|
- value: '2025-05-18T21:52:41+00:00'
|
|
changed:
|
|
- value: '2025-05-19T22:10:38+00:00'
|
|
promote:
|
|
- value: false
|
|
sticky:
|
|
- value: false
|
|
default_langcode:
|
|
- value: true
|
|
revision_translation_affected:
|
|
- value: true
|
|
path:
|
|
- alias: /daily/2025/05/18/how-quickly-can-you-get-back-online
|
|
langcode: en
|
|
body:
|
|
- value: "<p><a href=\"https://dora.dev/guides/dora-metrics-four-keys\">The DORA metrics</a> are four key metrics used to indicate the velocity and stability of software development.</p><p>They are:</p><ul><li>Deployment frequency - how often you successfully releases to production.</li><li>Lead time for changes - the amount of time it takes for a commit to get into production.</li><li>Change failure rate - the percentage of deployments causing a failure in production.</li><li>Time to restore service - the amount of time it takes to recover from a failure in production.</li></ul><p>If you had an issue after a release to production, how long would it take you to recover?</p><p>If the amount of changes is small and it hasn't been long since the last release, it could be easy to revert the code change and re-deploy.</p><p>If it's been a while since the last release or the release contains large changes, this will be harder.</p><p>If you use feature flags, can you disable a flag and stop the code that's causing the issue?</p><p>What if you need to recreate the whole environment?</p><p>How old is your most recent backup? Have you verified the backup works and can be used to restore a database, the user-uploaded files or the whole environment?</p><p>A backup is only good if it is recent and can be restored. Otherwise, it's useless.</p><p>But, restoring from backups can take time and lose data, so this should be the last option.</p><p>Releasing small changes often and using tools like feature flags will help minimise the downtime from an issue and allow service to be restored as quickly as possible.</p>"
|
|
format: basic_html
|
|
processed: "<p><a href=\"https://dora.dev/guides/dora-metrics-four-keys\">The DORA metrics</a> are four key metrics used to indicate the velocity and stability of software development.</p><p>They are:</p><ul><li>Deployment frequency - how often you successfully releases to production.</li><li>Lead time for changes - the amount of time it takes for a commit to get into production.</li><li>Change failure rate - the percentage of deployments causing a failure in production.</li><li>Time to restore service - the amount of time it takes to recover from a failure in production.</li></ul><p>If you had an issue after a release to production, how long would it take you to recover?</p><p>If the amount of changes is small and it hasn't been long since the last release, it could be easy to revert the code change and re-deploy.</p><p>If it's been a while since the last release or the release contains large changes, this will be harder.</p><p>If you use feature flags, can you disable a flag and stop the code that's causing the issue?</p><p>What if you need to recreate the whole environment?</p><p>How old is your most recent backup? Have you verified the backup works and can be used to restore a database, the user-uploaded files or the whole environment?</p><p>A backup is only good if it is recent and can be restored. Otherwise, it's useless.</p><p>But, restoring from backups can take time and lose data, so this should be the last option.</p><p>Releasing small changes often and using tools like feature flags will help minimise the downtime from an issue and allow service to be restored as quickly as possible.</p>"
|
|
summary: ''
|
|
field_daily_email_cta: { }
|