Delft Solutions - User contributions [en]

Ceph

2026-01-08T23:48:31Z

Dortund:

=== Configuring maintenance related ===

===== Add and remove `noout` flag on specific osd =====
* ceph osd add-noout osd.{id}
* ceph osd rm-noout osd.{id}

===== Add and remove 'noout' flag from node =====
* ceph osd set-group noout {node}
* ceph osd unset-group noout {node}

===== Enable/disable HA maintenance on a node =====
* ha-manager crm-command node-maintenance enable {node}
* ha-manager crm-command node-maintenance disable {node}

=== Permutation related ===

===== Destroy OSD =====
Needs to be executed on the node with the OSD
* ceph osd safe-to-destroy osd.{id}
* systemctl stop ceph-osd@{id}
* pveceph osd destroy {id}
*ceph-volume lvm zap /dev/sd[X] --destroy

===== Create OSD =====
Needs to be executed on the node with the OSD
* pveceph osd create /dev/sd[X] --encrypted 1 --crush-device-class hdd

===== Change device class =====
* ceph osd crush rm-device-class osd.{id}
* ceph osd crush set-device-class [hdd|ssd|nvme] osd.{id}

===== Reweight OSD =====
* ceph osd reweight {id} {weight}

Ceph

2026-01-08T23:48:06Z

Dortund:

==== Configuring maintenance related ====

===== Add and remove `noout` flag on specific osd =====
* ceph osd add-noout osd.{id}
* ceph osd rm-noout osd.{id}

===== Add and remove 'noout' flag from node =====
* ceph osd set-group noout {node}
* ceph osd unset-group noout {node}

===== Enable/disable HA maintenance on a node =====
* ha-manager crm-command node-maintenance enable {node}
* ha-manager crm-command node-maintenance disable {node}

==== Permutation related ====

===== Destroy OSD =====
Needs to be executed on the node with the OSD
* ceph osd safe-to-destroy osd.{id}
* systemctl stop ceph-osd@{id}
* pveceph osd destroy {id}
*ceph-volume lvm zap /dev/sd[X] --destroy

===== Create OSD =====
Needs to be executed on the node with the OSD
* pveceph osd create /dev/sd[X] --encrypted 1 --crush-device-class hdd

===== Change device class =====
* ceph osd crush rm-device-class osd.{id}
* ceph osd crush set-device-class [hdd|ssd|nvme] osd.{id}

===== Reweight OSD =====
* ceph osd reweight {id} {weight}

Ceph

2026-01-08T20:48:11Z

Dortund:

Ceph

2026-01-08T20:47:30Z

Dortund:

==== Configuring maintenance related ====
===== Add and remove `noout` flag on specific osd =====
* ceph osd add-noout osd.{id}
* ceph osd rm-noout osd.{id}

===== Add and remove 'noout' flag from node =====
* ceph osd set-group noout {node}
* ceph osd unset-group noout {node}

===== Enable/disable HA maintenance on a node =====
* ha-manager crm-command node-maintenance enable {node}
* ha-manager crm-command node-maintenance disable {node}

===== Destroy OSD =====
Needs to be executed on the node with the OSD
* ceph osd safe-to-destroy osd.{id}
* systemctl stop ceph-osd@{id}
* pveceph osd destroy {id}
*ceph-volume lvm zap /dev/sd[X] --destroy

===== Create OSD =====
Needs to be executed on the node with the OSD
* pveceph osd create /dev/sd[X] --encrypted 1 --crush-device-class hdd

===== Change device class =====
* ceph osd crush rm-device-class osd.{id}
* ceph osd crush set-device-class [hdd|ssd|nvme] osd.{id}

Ceph

2026-01-08T20:18:02Z

Dortund:

===== Add and remove `noout` flag on specific osd =====
* ceph osd add-noout osd.{id}
* ceph osd rm-noout osd.{id}

===== Add and remove 'noout' flag from node =====
* ceph osd set-group noout {node}
* ceph osd unset-group noout {node}

===== Destroy OSD =====
Needs to be executed on the node with the OSD
* ceph osd safe-to-destroy osd.{id}
* systemctl stop ceph-osd@{id}
* pveceph osd destroy {id}
*ceph-volume lvm zap /dev/sd[X] --destroy

===== Create OSD =====
Needs to be executed on the node with the OSD
* pveceph osd create /dev/sd[X] --encrypted 1 --crush-device-class hdd

===== Change device class =====
* ceph osd crush rm-device-class osd.{id}
* ceph osd crush set-device-class [hdd|ssd|nvme] osd.{id}

Ceph

2026-01-08T18:44:37Z

Dortund:

Ceph

2026-01-08T18:44:09Z

Dortund:

===== Add and remove `noout` flag on specific osd =====
* ceph osd add-noout osd.X
* ceph osd rm-noout osd.X

===== Add and remove 'noout' flag from node =====
* ceph osd set-group noout {node}
* ceph osd unset-group noout {node}

===== Destroy OSD =====
Needs to be executed on the node with the OSD
* ceph osd safe-to-destroy osd.{id}
* systemctl stop ceph-osd@{id}
* pveceph osd destroy {id}
*ceph-volume lvm zap /dev/sd[X] --destroy

===== Create OSD =====
Needs to be executed on the node with the OSD
* pveceph osd create /dev/sd[X] --encrypted 1

Ceph

2026-01-08T16:36:45Z

Dortund: Created page with " Add and remove `noout` flag on specific osd ``` ceph osd add-noout osd.X ceph osd rm-noout osd.X ``` Add and remove 'noout' flag from node ``` ``` Destroy OSD. Needs to be executed on the node with the OSD ``` ceph osd safe-to-destroy osd.{id} systemctl stop ceph-osd@{id} pveceph osd destroy {id} ceph-volume lvm zap /dev/sd[X] --destroy ``` Create OSD. Needs to be executed on the node with the OSD ``` pveceph osd create /dev/sd[X] --encrypted 1 ```"

Add and remove `noout` flag on specific osd
```
ceph osd add-noout osd.X
ceph osd rm-noout osd.X
```

Add and remove 'noout' flag from node
```

```

Destroy OSD. Needs to be executed on the node with the OSD
```
ceph osd safe-to-destroy osd.{id}
systemctl stop ceph-osd@{id}
pveceph osd destroy {id}
ceph-volume lvm zap /dev/sd[X] --destroy
```

Create OSD. Needs to be executed on the node with the OSD
```
pveceph osd create /dev/sd[X] --encrypted 1
```

Internal

2026-01-08T16:33:02Z

Dortund:

== Strategy ==
* [[Flow metrics|Flow metrics]]
* [[12%-time|12%-time]]

== Finance ==

=== Exact ===

* [[booking bonus|Booking bonus]]
* [[booking wages|Booking wages]]
* [[booking quarterly hosting invoice|Booking quarterly hosting invoice]]
* [[new receipt|Enter a new receipt]]
* [[reconciliation|Reconciliation of transaction]]
* [[invoicing|Send an invoice]]
* [[payment reminders|Send payment reminder]]
* [[invoice approval|Process for approving invoices (/filed receipts)]]

=== Bunq ===

* [[top up account|Top up expense account]]

== Work Process ==

* [[Definition of done|Definition of Done]]
* [[Incident Handling|Incident Handling]]
* [[SRE Maintenance|SRE Maintenance]]
* [[Release checklist|Release checklist]]
* [[Handover]]

== Internal Process ==
* [[timetracking|Timetracking process]]
* [[Starting work for a new client]]
* [[12 percent|12% time]]
* [[Annual leave|Annual leave]]
* [[Bonus allocation|Bonus allocation]]
* [[Calamity leave|Calamity leave]]
* [[Overtime|Overtime]]
* [[Retrospectives|Retrospectives]]
* [[Sick leave|Sick leave]]
* [[Training and self-study|Training and Self-Study]]
* [[Daily|Daily]]

== Projects ==

* Era Inventory [[project_era_inventory_api|API Description]]

== SRE ==

''To be further populated with guide from drive''
* [[create gitlab runner host|Create a GitLab runner host]]
* [[vm setup|Create a (Debian) VM]]
* [[border update|Process for updating a border]]
* [[border reboot|Reboot border without downtime]]
* [[ceph|Common Ceph commands]]
* [[WS Proxmox node reboot|Reboot WS Proxmox node without downtime]]
* [[Resize VM Disk]]
* [[SRE tools]]
* [[Enroll Mac in Kerberos]]
* [[New Mac Setup]]
* [[Creating a VM on Hetzner]]
* [[Rebooting VM]]
* [[Rebooting Offsite]]
* [[ssh-fingerprints|Verifying SSH fingerprints]]
* [[Removing VM]]
* [[Install a new Disk in Server]]
* [[Setting Up Wildcard Subdomains with SSL on a Debian Application]]
* [[s3 bucket backup|Get credentials to backup S3 bucket to Zombie]]
* [[Hardware Incident Response: Memory Slot Failure on banshee]]
* [[dfz switch setup|DFZ Switch setup]]
* [[Update Zulip Server version]]
* [[update-sentry|Update Sentry]]
* [[iDRAC: Upload a new pem certificate for automatic updates]]
=== SLA ===
* [[Response for Backup Service being down for an extended period of time]]

== Other ==

* [[stack|Greenfield stack]]
* [[standard tools|Standard Tools]]
* [[list of unfurl debuggers|List of unfurl debuggers]]
* [[Recommended suppliers]]

Update Zulip Server version

2025-10-30T20:10:18Z

Dortund:

'''Context:'''
This procedure was written at the time of Zulip 11.4, and applies to upgrades performed on the chat.dsinternal.net server.

'''Important Notes'''
* It is possible (and supported) to upgrade across multiple versions at once — there is no need to install each intermediate release.
* Always consult the official Zulip upgrade documentation first. It supersedes this checklist:
https://zulip.readthedocs.io/en/latest/production/upgrade.html
* Make sure to note any important and relevant details concerning the next upgrade(s) reading the upgrade notes for every upcoming major version:
https://zulip.readthedocs.io/en/latest/overview/changelog.html
* In our case we're following the upgrading-to-a-release method not the upgrading-from-a-git-repository one.
* Read any version-specific upgrade notes in the official docs before proceeding.

== Pre-upgrade Steps ==
# Read the [https://zulip.readthedocs.io/en/latest/overview/changelog.html upgrade notes] and prepare accordingly if some specific actions need to be taken
# Make sure the Debian and PostgreSQL versions are compatible with the upcoming update
# Schedule and announce the maintenance window
# Create a maintenance period in Zabbix
# Create a backup and/or snapshot

== Upgrade Procedure ==
'''Important Notes'''
This procedure is taken from the official doc, if official doc has been updated this checklist should be updated to
# Fetch the latest build <code>curl -fLO https://download.zulip.com/server/zulip-server-latest.tar.gz</code>
# Run the upgrade <code>/home/zulip/deployments/current/scripts/upgrade-zulip zulip-server-latest.tar.gz</code>
# Monitor the process, expect temporary CPU and memory spikes right after the upgrade due to migrations and cache rebuilds. You probably want to wait for things to settle down before going on to next steps.

== Post-upgrade Tasks ==
# Update the settings.py file following the method described [https://zulip.readthedocs.io/en/latest/production/upgrade.html#updating-settings-py-inline-documentation here]
# Once you've made sure everything is running as expected remove the snapshot and maintenance period

== Note ==
See this message for configuration details regarding email: https://chat.dsinternal.net/#narrow/channel/4-SRE-.23.23-Non-critical/topic/Zulip.20inbound.20email.20bounces/near/62829

WS Proxmox node reboot

2025-10-06T14:16:27Z

Dortund:

== Tips & Notes ==
* If you're expecting to reboot every node in the cluster, do the node with the containers last, to limit the amount of downtime and reboots for them
* Updating a node: `apt update` and `apt full-upgrade`
* Make sure all VMs are actually migratable before adding to a HA group
* If there are containers on the device you are looking to reboot- you are going to need to also create a maintenance mode to cover them (for example teamspeak or awstats)
* Containers will inherit the OS of their host, so you will also need to handle triggers related to their OS updating, where appropriate
== Pre-Work ==
* If a VM or container is going to incur downtime, you must let the affected parties know in advance. Ideally they should be informed the previous day.

== Pre-flight checks ==
* Check all Ceph pools are running on at least 3/2 replication
* Check that all running VM's on the node you want to reboot are in HA (if not, add them or migrate them away manually)
** '''The `compute.*` VM's are not to be migrated! Rebooting a node with such a VM present requires shutting down the VM!'''
* Check that Ceph is healthy -> No remapped PG's, or degraded data redundancy
* You have communicated that downtime is expected to the users who will be affected (Ideally one day in advance)

== Update Process ==
* Update the node: `apt update` and `apt full-upgrade`
* Check the packages that are removed/updated/installed correctly and they are the sane (to make sense)

== Reboot process ==
* Complete the pre-flight checks
* If you want to reboot for a kernel update, make sure the kernel is updated by following the Update Process written above
* Start maintenance mode for the Proxmox node and any containers running on the node
* Start maintenance mode for Ceph, specify that we only want to surpress the trigger for health state being in warning by setting tag `ceph_health` equals `warning`
* Let affected parties know that the mainenance period you told them about in the preflight checks is about to take place.
[[File:Ceph-maintenance.png|thumb]]
* Set noout flag on host: `ceph osd set-group noout <node>`

# gain ssh access to host
# Log in through IPA
# Run the command
* '''Reboot''' node through web GUI
* Wait for node to come back up
* Wait for OSD's to be back online
* Remove noout flag on host: `ceph osd unset-group noout <node>` ,to do this:
* If a kernel update was done, manually execute the `Operating system` item manually to detect the update. Manually executing the two items that indicate a reboot is also usefull if they were firing, to stop them/check no further reboots are needed.
* Ackowledge & close triggers
* Remove maintenance modes

== Aftercare ==
* Ensure that Kaboom API is running on Screwdriver or Paloma. This is to get the best performance for the VM.

Response for Backup Service being down for an extended period of time

2025-03-14T14:47:14Z

Dortund: Created page with "If our current backup service ever becomes unavailable for an extended period of time (extended being longer than our required period for making a backups), we'll have to make backups with an alternative service. The advice would be the following: * Set up a Proxmox Backup Server VM on Pistol: https://pbs.proxmox.com/docs/installation.html * There are unassigned disks on Pistol. Those should be assigned to the PBS VM * Set up credentials for ** Offsite ** WS Cluster ** S..."

If our current backup service ever becomes unavailable for an extended period of time (extended being longer than our required period for making a backups), we'll have to make backups with an alternative service. The advice would be the following:
* Set up a Proxmox Backup Server VM on Pistol: https://pbs.proxmox.com/docs/installation.html
* There are unassigned disks on Pistol. Those should be assigned to the PBS VM
* Set up credentials for
** Offsite
** WS Cluster
** S3 VM's
* Configure these hosts to use the newly set up PBS service

Note: Since this has likely not been done before, everything (VM's, buckets) need to have an 'initial' backup made of them. This is not a special process, but it means that ALL of their data needs to be read and transferred. This significantly more time than making the next sequential backups, so you'll want to start with making backups of the critical services, such as client VM's and buckets, and start the backups on time before any deadlines.

Internal

2025-03-14T14:38:59Z

Dortund: /* SRE */

== Strategy ==
* [[Flow metrics|Flow metrics]]
* [[12%-time|12%-time]]

== Finance ==

=== Exact ===

* [[booking bonus|Booking bonus]]
* [[booking wages|Booking wages]]
* [[booking quarterly hosting invoice|Booking quarterly hosting invoice]]
* [[new receipt|Enter a new receipt]]
* [[reconciliation|Reconciliation of transaction]]
* [[invoicing|Send an invoice]]
* [[payment reminders|Send payment reminder]]
* [[invoice approval|Process for approving invoices (/filed receipts)]]

=== Bunq ===

* [[top up account|Top up expense account]]

== Work Process ==

* [[Definition of done|Definition of Done]]
* [[Incident Handling|Incident Handling]]
* [[SRE Maintenance|SRE Maintenance]]

== Internal Process ==
* [[timetracking|Timetracking process]]
* [[Starting work for a new client]]
* [[12 percent|12% time]]
* [[Annual leave|Annual leave]]
* [[Bonus allocation|Bonus allocation]]
* [[Calamity leave|Calamity leave]]
* [[Overtime|Overtime]]
* [[Retrospectives|Retrospectives]]
* [[Sick leave|Sick leave]]
* [[Training and self-study|Training and Self-Study]]
* [[Daily|Daily]]

== Projects ==

* Era Inventory [[project_era_inventory_api|API Description]]

== SRE ==

''To be further populated with guide from drive''
* [[create gitlab runner host|Create a GitLab runner host]]
* [[vm setup|Create a (Debian) VM]]
* [[border update|Process for updating a border]]
* [[border reboot|Reboot border without downtime]]
* [[WS Proxmox node reboot|Reboot WS Proxmox node without downtime]]
* [[Resize VM Disk]]
* [[SRE tools]]
* [[Enroll Mac in Kerberos]]
* [[New Mac Setup]]
* [[Creating a VM on Hetzner]]
* [[Rebooting VM]]
* [[Rebooting Offsite]]
* [[ssh-fingerprints|Verifying SSH fingerprints]]
* [[Removing VM]]
* [[Install a new Disk in Server]]
* [[Setting Up Wildcard Subdomains with SSL on a Debian Application]]

=== SLA ===
* [[Response for Backup Service being down for an extended period of time]]

== Other ==

* [[stack|Greenfield stack]]
* [[standard tools|Standard Tools]]
* [[list of unfurl debuggers|List of unfurl debuggers]]
* [[Recommended suppliers]]

Booking wages

2025-01-07T13:54:56Z

Dortund:

== Wage slips ==

# Exact
# Financieel > Boekingen en grootboekrekeningen > Boekingen > Aanmaken (English: Financial -> Entries & G/L Accounts -> Entries -> Create)
# Inkoop > '''80 - Salarisstroken'''
# Add file (wage slip)
# Set `Supplier` to the person this wage slip meant for
# Beschijving: Salaris periode {YEAR}-{MONTH}-M / {YEAR}-{MONTH}-M {NAME}
# Ensure `Payment condition` is set to `M - Einde volgende maand`
# Ensure `Invoice date` is set to the beginning of the month the wage slip pertains to
# Totaalbedrag: Set to '''Totaal netto''' from the wage slip
# Line items:
## From the wage slip's '''Bruto > Salaris''' add the value of it as '''Bruto loon (4000)''', with description 'Salaris periode {YEAR}-{MONTH}-M / {YEAR}-{MONTH}-M {NAME}'
## From the wage slip's '''Bruto > Bonus (BT)''' if present, add the value of it as '''Te betalen bonussen (1790)''' with description 'Salaris bonus {YEAR}-{MONTH}-M / {YEAR}-{MONTH}-M {NAME}'
## From the wage slip's '''Loonheffing''' add the value of it as a negative amount as '''af te dragen loonheffing (1700)''', with description 'Salaris LH {YEAR}-{MONTH}-M / {YEAR}-{MONTH}-M {NAME}'
## From the wage slip's '''Netto > Onkostenvergoeding''' if present, add the value of it as '''Kosten nettovergoedingen'''

== Wage taxes ==
# Exact
# Financieel > Boekingen en grootboekrekeningen > Boekingen > Aanmaken
# Inkoop > '''80 - Salarisstroken'''
# Add file (LH/'Loonaangifte_Bedrijf_Overzicht_Delft_Solutions_BV_*.pdf)
# Set `Supplier` to `Belastingdienst`
# Beschrijving: Enter the value for ''LHnummer en volgnummer'' from the document
# Ensure `Payment Condition` is set to `D - Deze maand`
# Ensure `Invoice date` is set to the beginning of the month, if the 'send' date on the document is not of the current month. Otherwise, just set the 'send' date
# Set `Total amount` to the value of `Totaal Generaal` from the document
# Line items:
## From the document's '''Loonbelasting / premie volksverzekering''' add the section's total value as '''Af te dragen loonheffing (1700)''' with description `Loonbelasting / premie volksverzekering {YEAR}-{MONTH}`
## From the document's '''Premies''' add the section's total value as '''Kosten sociale premies werkgever (4041)''' with description `Premies {YEAR}-{MONTH}`

== Pension ==

# Exact
# Financieel > Boekingen en grootboekrekeningen > Boekingen > Aanmaken
# Inkoop > '''80 - Salarisstroken'''
# Add file (JP/'Journaalposten_Delft_Solutions_BV_*.pdf)
# Set `Supplier` to `Bright Pensions N.V.`
# Beschrijving: Pensioen {YEAR}-{MONTH}-M
# Ensure `Payment condition` is set to `IN - Incasso`
# Ensure `Invoice date` is set to the the '16th' of the month of the period over which the document documents the pension payments. (Look at 'Periodes' for this)
# Totaalbedrag: Set to the value of '''Pensioenafdracht WG en WN''' on the document
# Line items:
## For each person who received pension payment: '''Pensioenen (4011)''' with description `Pensioen {YEAR}-{MONTH}-M {NAME}` and with the correct value (At the moment, 1/3 of the total amount per person).

== Reconciliation (after payment) ==
# Financieel > Boekingen en grootboekrekeningen > Overzichten > Kaarten (In English: Financial > Entries & G/L Accounts > Reports > Transactions)
# Search for '''Af te dragen loonheffing (1700)'''. Ensure the relevant `Financial year` is selected.
# First, only mark (not actually match) the wage slips together with the IRS slip for wage taxes. The difference at the bottom (e.g. 0.16 EUR) needs to be added to the wage tax document.
## For line item '''Af te dragen loonheffing (1700)''' add the difference to the current value (0.16 EUR in this example)
## Create line item '''Rekenverschillen (9200)''' with description {ENTRY_DESCRIPTION} {YEAR}-{MONTH} and the value in negative (-0.16 EUR in this example)
## Mark the wage slips together with the IRS slip for wage taxes again. The difference should now be 0.
# Select `Match` at the top of the screen to match the entries.

== Reconciliation of the payment itself ==
# Go to Financial > Banking & Cash > Statements > To be completed and search for `to be completed` statements.
# Ensure the G/L account is set to `1671 - Te betalen lonen`, and the account is set to `1 - Belastingdienst`.
# Select `Match` and select the matching entry (Previously created in the `Wage Taxes` section).

== Reconciliation of the pension payments ==
# Go to Financial > Banking & Cash > Statements > To be completed and search for `to be completed` statements.
# Ensure the G/L is set to `1671 - Te betalen lonen`, and the account is set to `47 - Bring Pensions N.V.` for the three pension payments.
# Click 'Match' on any of the pension payments
# In the modal, check the checkbox for the other two pension payments, and the correct pension document entry (The one created earlier in the `Pension` section). Finally, click `Enter`.

== Preparing wage payments ==
# Create a payment scheduled on the correct date (15th of the month) for 12:00 (Midday), for each wage slip added, with the description `Salaris periode {YEAR}-{MONTH}-M {NAME}`

Invoicing

2025-01-02T14:07:22Z

Dortund:

# Log in to Exact.
# Go to the Sales module in the top bar.
# Select 'Invoices'.
# Click 'Create'.
# Select the correct journal TODO: get better reference on the page on what to click
# Choose the customer from the dropdown list for the 'ordered by' property.
# Enter the 'Order date'. The current date is likely fine.
# Specify the payment terms and due date by making sure the 'Payment condition' is properly set.
# Set the reason/description of the invoice in 'Description'. (I.E.: Account deletion feature)
# Add the product(s) or service(s) by clicking 'Add Line Item'.
# Input the quantity, unit price, and tax rate.
# Add any necessary discounts or additional charges.
# To add a discount, click the settings area in the invoice menu and enable discounts, save your settings.
# Enter the discount value (e.g., 10%).
# Add a description for the discount (optional).
# Click 'Save' to apply the discount to the invoice.
# Click 'Save' to generate a draft invoice.
# Review the invoice for accuracy.
# Click 'send based on account' to do final review, and select email by which to send.

== Notes ==
If you are missing columns for items (such as 'Description') you can add them by clicking the 'triple dot' button in the top right and selecting customize. Finally, check the checkbox for the columns you want to have.

Incident Handling

2024-12-19T10:13:56Z

Dortund:

== Zulip migration ==
Due to a migration to Zulip, the integration as was available on Mattermost is not available yet on Zulip. This leads to the following process changes:
* Acknowlegements and triggers resolving are not posted to Zulip by Zabbix
* Triggers are grouped in a topic on Zulip per host
* When an incident has been fully resolved, mark the topic as resolved, when any other incidents reported for the host are resolved
* There's no `?ongoing`, instead for now we can track open incidents by checking for unresolved topics
* The posting of incidents is less smart (only posting when not posted yet), so in order to prevent an incident from not being reported due to network issues or the likes, a message is posted after an inteval (8 hours for non-critical and lower, 1 hour for critical and above) while the incident has not been acknowleged.
* Incidents can be manually tracked by creating a topic by hand and reporting the problem.
* There is no automatic gitlab issue creation or syncing anymore.

Finally, where this process says to do something on Mattermost, you should now do so on Zulip. The updates in the process chapters themselves are WIP.

== Critical incidents ==
'''Critical incidents are resolved within 16 hours.'''

As first responder you take on the responsiblity of seeing an incident resolved. This does not mean that you are the person required to do all the work. You can attempt to involve other to help you (often referred to as escalating the incident), but since other are not on-call, they are not obliged to help you, especially outside of normal working hours.
Involving multiple people can quickly be required if multiple critical incidents with different causes occur simultaniously. In that case, the First Responder usually takes on a more information management role and steers those that are brought on into resolving the issues. (Example: if a server crashes, several critical triggers can fire, but the underlying cause can quite quickly be determined to be a single issue, the crashed server. So you wouldn't need to call in people to manage each incident. But a client's service being down in one cluster while in a different cluster a different VM no longer boots is likely to be to different issues, so in order to resolve them on time you'd want to call in help to resolve the incident in time).

=== Process ===
The general process is made up of the folowing steps. Each step has additional information on how to handle/execute them in the sections below.
# Take responsibility for seeing the incident resolved
# Determine if incident is still ongoing
# If ongoing: Communicate to affected clients that the issue is being investigated
# Communicate plan/next steps (even if that is gathering information)
# Communicate findings/results of executed plan, go back to previous step if not resolved
# Resolve incident + cleanup

During working on an incident it is expected that all communication is done in the incident's thread. This means all information to a problem can be found in a clear a predictable place. Sometimes an incident can be resolved by work done in another incident. In that case, it is required to post a link to that thread in the incident's thread with the comment that the resolution is done in that thread.

==== Acknowledge the incident on Zabbix ====
The first step is to take responsibility for seeing the incident resolved by acknowledging the incident on Zabbix. Simply acknowledging the trigger suffices. It is however entirely possible that multiple critical incidents are firing at the same time. This can be a coincidence, or can be because of a share cause of failure. For example, a server crashing will cause server VM' to reboot, or the router having an connectivity issue will lead to most other VM's having connectivity issues as well. If there are multiple critical incidents, it is advised to quickly observe what's ongoing, Zabbix is the best source of firing triggers for this, and pick the incident that is likely the root cause to

* Acknowledging an incident on Zabbix will stop Zabbix from calling the First Responder to notify them of the ongoing incident. And stops Zabbix from posting reminders on Zulip.

==== Determine if incident is still ongoing ====
The next step is to check if the reported problem is still ongoing. Depending on the observations made here your process to follow and steps needed to resolve the incident can change. There are three options:
# The trigger resolved itself and the problem cannot be observed. Example: HTTPS is down for a site, but the FR can access the site through HTTPS without incident.
# The trigger resolved itself and the problem can still be observed.
# The trigger is still firing but the problem cannot be observed: Our triggers might not be perfect, so it could be that something else is causing it to fire. A simple example would be that Zabbix reports that the the DNS for a site can't be resolved, but in reality there's a bug in the script we wrote that checks if the DNS resolves and the DNS resolves fine. Final note: keep in mind that an 'it works on my machine' does not necessarily mean it works for most other people, so depening on the trigger you need to do some evaluations if your tests suffice.

In order to make sure you are actually trying to observe the same thing as the trigger is looking for, make sure to check the trigger definition and the current data of the associated item(s). Some triggers might fire if one of multiple conditions is met (Such as a trigger that monitors the ping response time firing if the value exceeds a certain threshold, or if no data for a certain period of time was observed).

Make sure to report your findings in the incident's thread. It's advised to post a screenshot of the relevant item(s) and your own observations. (Continuing the ping example, you would post a screenshot of the relevant values, state your conclusion why the trigger is firing, and your own observations/pings)

==== Communicate to affected clients ====
If the incident is still ongoing and the service is down, we need to communicate to affected clients that we are aware of the problem and that we are investigating it. This is because critical incident usually mean the service is down, something the clients can notice/are affected by, so we to be transparent that something is going on. There are some additional notes to this though:
* If an incident has already resolved itself and the problem is no longer observable, we don't communicate anything. Doing so might only cause confusion, and since the client has not reported any issues, they have not had a noticeable problem with it themselves.
* Although a critical incident generally means that the client service is down or experiencing reduced service, not all critical incidents are of that nature. Some are more administrative, or are only an issue for Delft Solutions itself. As of writing I don't have an exhaustive list, but here is those I can think of:
** SSH Service is down: We don't have any clients that SSH into their services, so it's generally not a problem. But SSH is mostly used for SRE maintenance and publishing new builds. The SRE maintenance is an internal problem, so no need to communicate to the client. The publishing is done to Kaboom, preventing new builds from being published, and the two SM VM's.
** No backup for x days: Clients don't notice it if a backup is running late, so no need to communicate with clients. Just need to make sure the backup gets completed
** SSL certificate is expiring in < 24 hours: This is a bit dependent on how soon this incident is being handled, but if it handled quickly, the certificate never actually expired, and there has not been any disruption to the client's service, so no need for communicating about it.
* Determining which clients are being affected can be done by looking at the host's DNS in the trigger, and/or looking up the VM in Proxmox and checking the tags of the VM's for client names. In the case that this issue is causing multiple other critical triggers to fire, you would have to check for which clients are affected by those incidents.
* Communicating to DS about ongoing incidents is usually assumed to be automaticly have been done by the fact that the incident was reported on Zulip.

As always, report the decisions taken and actions maded in the incident thread. (e.g.: I've sent a message in the Slack to let Kaboom know that we aware of problem x, and that we are investigating it)

==== Communicate plan/next steps + Communicate findings/results of executed plan ====
This is the main part of handling an incident. There are several actions you can take in these steps, but at the basis they consist of sharing your next steps, performing those, and reporting the results. The reason all this needs to be reported is to ensure that all known information about a problem is logged, making it easier for someone else to be onboarded into the issue, for later reference if a similar issue is encountered, and even for use during the incident itself in case an older configuration needs to be referenced after you changed it.
The objective from these steps is determining what is actually wrong and how to resolve it. Depending on the observations made earlier on whether the incident is still ongoing and is (still) observable your investigation can go into different directions. (e.g. Find the underlying cause for a trigger, or determining why the trigger is firing while it likely shouldn't, and then how to resolve that underlying cause or how to update the trigger to work better)

There are three main types of steps defined, but you are not limited to these:
# Hypothesis: If you have an idea what could be causing it, you would state your hypothesis and your next step would be to prove that hypothesis. For example, for an incident 'SSH service is down on X' your hypothesis could be that this is due to 'MaxStartups' throttling, which can be proven by 'grep'ing journalctl for that, and compare the start and end times of throttling with the timestamps of the item reporting the status of the SSH service.
# Information gathering: Sometimes it just helps to get some facts about the situation collected. What is usefull information that is relevant depends on the triggers, but some examples are: The syslog/journalctl of the host from around the time of the incident (it can contain a reference to the an underlying problem in various levels of explicitness), the ping response from several hosts on the route to a host or a traceroute (this helps with networking issues). The gathered information is usually intended to help you come up with an hypothesis on what's wrong.
# Investigative: The most rigorous of process. The full process is described here originally [https://docs.google.com/document/d/1AQYJM1Q9l2Tyk6zfCVaQ2aEq-dpbfUH5okE88bpKkhw/edit#heading=h.5fq2skijqbdc Drive - Final Coundown - General Investigative Process]. To summarize, when you don't know why something is failing, and/or don't have any decent hypotheses to follow up, you can follow this process to systematicly find the problem.

Regarding the resolution to an incident: The resolution to any incident is usually one of two things:
# Fix the underlying problem.
# Fix the trigger itself.
Fixing the trigger is relavively straightforward, but do make sure document in the thread what you changed to which trigger.
Fixing the underlying problem can be more complex. A trade-off needs to be made sometimes between resolving technical debt, or simply patching the current system to resolve the issue. We usually look for a resolution that ensures that the problem won't re-occur soon, or makes it unexpected/unlikely for the problem to re-occur. Taking into account the timeframe that is available to resolve the incident you can make some trade-offs. An example would be: normal backups of VM's are failing due to the Proxmox backup server being down/unreachable and it is determined that this cannot be resolved at that moment. We can set up automatic backups to local storage temporary to resolve the immediate problem and ensure we keep our SLO's versus setting up a new Proxmox Backup server at a different location. Since we don't have much time to resolve the problem, the resolution would be to set up the automatic backups to local storage, and set up a new Proxmox Backup Server later as a seperate issue.

===== Some known issues and their resolutions =====
* SSH service is down: The internet is a vile place. There's constant port scanning and hacking attempts ongoing to any machine connected to the internet (mostly IPv4). Due to this, SSH has a throttling functionality build in to prevent a system from being DDOS'ed by the amount of malicious SSH requests. This throttling can cause the Zabbix server from being denied an SSH connection, of which several failures fire this trigger. This hypothesis can be proven with a `journalctl -u ssh | grep 'MaxStartups throttling'` (you probably want to select a relevant time period with `--since "2 hours ago"` or something similar to prevent having to process a month of logging). You can then compare the throttling start and end times with the timestamps of the item data itself. The resolution for the issue is to add our custom ssh configuration [https://chat.dsinternal.net/#narrow/stream/23-SRE---General/topic/DS.20Whitelisted.20Custom.20SSH.20configuration/near/1620 Custom SSH Configuration].
* No backup for 3 days: Are S3 backup is very slow. Not much to prove as an underlying issue here. What needs to be done is check that the backup process is ongoing. The Zabbix latest data can be checked to verify that backups are running by checking that that days backups were done for the smaller buckets. The devteam email can be checked for if the backup process could not start on day due to it already running (it takes 24+ hours, and an attempt to start it is done each day by cron).
* git.* HTTPS is down: On Sunday mostly, Gitlab gets automaticly updated, but this incurs some downtime as the service is restarted. This is usually short enough to not be reported to Zulip as per our settings, but sometimes it's longer. If the service does not stay down, the issue can be just resolved.

==== Resolve incident + cleanup ====
When you've executed and verified the resolution in the previous steps we can proceed resolving the issue in our Mattermost integration. Resolving an incident can be done by doing the following:
# Verify that the trigger is no longer firing. An incident will be immediatly re-opened if the trigger is still firing, and the incident cannot be considered resolved if the trigger is still firing. If the trigger is still firing but you're sure that you've resolved the problem, you might need to force the item the trigger depends on to update. This can be done by finding the item in the host's configuration on Zabbix and selecting 'Execute Now', after a short period this should force Zabbix to re-execute the item. You can check the timestamps in the latest data of an item to check if it was updated.
# Close the incident by marking the topic as resolved, when there are no other triggers firing for the host.

Unfortunatly, some problems cause multiple critical and non-critical triggers to fire. This means we have to check Zabbix and Zulip for other fired triggers and ongoing incidents. The goal is to identify critical and non-critical incidents that were caused by the incident/underlying issue you just resolved.
# First, these incidents need to be acknowledged on Zabbix, and in the acknowledgement message you mention the incident/problem that caused this.
# Next, check the incident tracked by the integration on Mattermost using the `?ongoing` command. Resolve incidents that were (re-)opened by this incident by executing the following steps. If the first two fail (problem still persists, trigger is still firing), the incident needs to considered it's own issue and the relevant process needs to be followed (critical or non-critical depending on criticality).
## Ensuring the mentioned problem is no longer observable
## The trigger has resolved (You might need to force an update with `Execute Now`).
## Posting a link to the main incident you resolved with the comment that the underlying problem was resolved in that topic.
## Closing the incident by marking the topic as resolved, when there are no other triggers firing for the host.

When you are done, there should be no more critical triggers firing in Zabbix or open in the Zabbix-Mattermost intergration, for which no-one has taken responsibility or you have taken responsibility for and are not actively handling.

===Additional context===
* Critical incidents are posted in [https://chat.dsinternal.net/#narrow/stream/24-SRE-.23-Critical '''SLA - Critical'''].
* <s>When it is being tracked on GitLab a heavy check mark is added to the message.</s>
* <s>Responses on the thread and on GitLab are automatically synced (to some extend)</s>
* <s>When you reply with '''I agree that this has been fully resolved''' eventually our Zabbix-Mattermost integration will pick this up and a green check mark is added to the message.</s>

== Non-Critical incidents ==
* Non-critical incidents are acknowledged within 9 hours and resolved within one week.

=== Acknowledging ===
Fully acknowledging a non-critical incident requires the following tasks to have been completed:
* Acknowledging the incident on Zabbix, which means you take responsibility of completing the steps listed below.

The next steps don't have to be done immediatly, as they have dependencies, but be started and scheduled for completion the next work day.

Check if there's already a uncompleted milestone for this host with this issue in the metrics sheet.
If a milestone is already present:
* Report in the topic the Lynx project ID for resolving this issue.
* If the ID has already been reported in the topic, we don't want to report it again and again, instead add the 🔁 emoji (:repeat:) under the zabbix bot alert

If a milestone is NOT already present:
* Add the non-critical incident as a milestone in the metrics sheet, following the naming convention
** Start date is the date of the incident
** DoD states what needs to be true for the non-critical incident to be consider resolved
* Add the non-critical incident to Lynx as a project
** Follow the naming convention below for the title & project ID
** Tasks need to be added
** Final tasks needs to have the SLO deadline set as 'contraint'
** Project priority is set to 99 while not estimated yet. After the estimation is done, the priority should be set to 20
** The tasks are estimated for SP
* The Lynx project ID is reported in the non-critical incident's topic on Zulip, and logged in the metrics sheet
* A Kimai activity is created in Kimai for the non-critical incident, following the naming convetion

==== Naming convention ====
* Kimai activity name needs to follow the pattern: '<YYYY-MM> <problem_title>'. For <problem_title>, incorporate the trigger title and hostname for clarity.
* Milestone name needs to follow the pattern: 'Delft Solutions Hosting Incident response work <kimai_activity_name>'
* Lynx project name needs to follow the pattern: 'Delft Solutions Hosting Incident response work <kimai_activity_name>'
* Lynx project ID needs to follow the pattern: 'SRE<YYMM><XXX>', where <XXX> is some three letter shorthand that relates to the problem/host

== Informational incidents ==
* Informational incidents are acknowledged within 72 hours

Checklist
# Acknowledge on Zabbix
# Sanity check the event, post result in thread
# If action needed, perform action

== If an incident is reported by other means than the Zabbix-Zulip intergration ==
# Acknowledge receipt.
# Classify the incident as critical, non-critical, or informational.
# Create an topic in the relevant SRE channel, stating the problem and that you is responsible for resolving it.
# Proceed to treat the incident according to the criticality you just classified it as. (So for a critical incident, it means you now start the critical incident handling process)

== Handover ==
When handing over the responsibility of '''first responder''' (FR), the following needs to happen:
* The handover can be initiated by both the upcoming FR or the acting FR
* Acting FR adds the upcoming FR the the IPA sla-first-responder user group and enables Zabbix calling for that the upcoming FR if they have that set by going to Zabbix > Configuration > Actions > [https://status.delftinfra.net/zabbix/actionconf.php?eventsource=0# Trigger actions]
* The upcoming FR makes sure they are aware of the state of the SLA and knows what questions they wants to ask the acting FR.
* The upcoming FR makes sure they are subscribed to the right channels.

The following steps can be done async or in person:
* The acting FR announces/informs the upcoming FR has been added to the sla-first-responder group (In Zulip's [https://chat.dsinternal.net/#narrow/stream/13-Organisational Organisational channel] if asynq).
* If the acting FR wants to hand over responsibility for any ongoing incident they also state which incidents they want the upcoming FR to take over.
* If there are any particularities the upcoming FR needs to be aware of, those are shared.
* The upcoming FR asks their questions until they are satisfied and able to take over the FR
* The upcoming FR ensures they are subscribed to the following channels on Zulip: [https://chat.dsinternal.net/#narrow/stream/23-SRE---General SRE - General], [https://chat.dsinternal.net/#narrow/stream/24-SRE-.23-Critical SRE # Critical] and if part of the SRE team [https://chat.dsinternal.net/#streams/4/SRE%20##%20Non-critical SRE ## Non-Critical] and [https://chat.dsinternal.net/#streams/5/SRE%20###%20Informational SRE ### Informational].
* The upcoming FR announces/informs that they are now the acting FR over Zulip's [https://chat.dsinternal.net/#narrow/stream/13-Organisational Organisational channel]
* The now acting FR removes the previous FR from IPA the sla-first-responder user group and disables Zabbix calling for the previous FR if they had that enabled by going to Zabbix > Configuration > Actions > [https://status.delftinfra.net/zabbix/actionconf.php?eventsource=0# Trigger actions]

Incident Handling

2024-12-19T09:44:08Z

Dortund: Changed chapter to have a header, and fixed a typo

== Zulip migration ==
Due to a migration to Zulip, the integration as was available on Mattermost is not available yet on Zulip. This leads to the following process changes:
* Acknowlegements and triggers resolving are not posted to Zulip by Zabbix
* Triggers are grouped in a topic on Zulip per host
* When an incident has been fully resolved, mark the topic as resolved, when any other incidents reported for the host are resolved
* There's no `?ongoing`, instead for now we can track open incidents by checking for unresolved topics
* The posting of incidents is less smart (only posting when not posted yet), so in order to prevent an incident from not being reported due to network issues or the likes, a message is posted after an inteval (8 hours for non-critical and lower, 1 hour for critical and above) while the incident has not been acknowleged.
* Incidents can be manually tracked by creating a topic by hand and reporting the problem.
* There is no automatic gitlab issue creation or syncing anymore.

Finally, where this process says to do something on Mattermost, you should now do so on Zulip. The updates in the process chapters themselves are WIP.

== Critical incidents ==
'''Critical incidents are resolved within 16 hours.'''

As first responder you take on the responsiblity of seeing an incident resolved. This does not mean that you are the person required to do all the work. You can attempt to involve other to help you (often referred to as escalating the incident), but since other are not on-call, they are not obliged to help you, especially outside of normal working hours.
Involving multiple people can quickly be required if multiple critical incidents with different causes occur simultaniously. In that case, the First Responder usually takes on a more information management role and steers those that are brought on into resolving the issues. (Example: if a server crashes, several critical triggers can fire, but the underlying cause can quite quickly be determined to be a single issue, the crashed server. So you wouldn't need to call in people to manage each incident. But a client's service being down in one cluster while in a different cluster a different VM no longer boots is likely to be to different issues, so in order to resolve them on time you'd want to call in help to resolve the incident in time).

=== Process ===
The general process is made up of the folowing steps. Each step has additional information on how to handle/execute them in the sections below.
# Take responsibility for seeing the incident resolved
# Determine if incident is still ongoing
# If ongoing: Communicate to affected clients that the issue is being investigated
# Communicate plan/next steps (even if that is gathering information)
# Communicate findings/results of executed plan, go back to previous step if not resolved
# Resolve incident + cleanup

During working on an incident it is expected that all communication is done in the incident's thread. This means all information to a problem can be found in a clear a predictable place. Sometimes an incident can be resolved by work done in another incident. In that case, it is required to post a link to that thread in the incident's thread with the comment that the resolution is done in that thread.

==== Acknowledge the incident on Zabbix ====
The first step is to take responsibility for seeing the incident resolved by acknowledging the incident on Zabbix. Simply acknowledging the trigger suffices. It is however entirely possible that multiple critical incidents are firing at the same time. This can be a coincidence, or can be because of a share cause of failure. For example, a server crashing will cause server VM' to reboot, or the router having an connectivity issue will lead to most other VM's having connectivity issues as well. If there are multiple critical incidents, it is advised to quickly observe what's ongoing, Zabbix is the best source of firing triggers for this, and pick the incident that is likely the root cause to

* Acknowledging an incident on Zabbix will stop Zabbix from calling the First Responder to notify them of the ongoing incident. And stops Zabbix from posting reminders on Zulip.

==== Determine if incident is still ongoing ====
The next step is to check if the reported problem is still ongoing. Depending on the observations made here your process to follow and steps needed to resolve the incident can change. There are three options:
# The trigger resolved itself and the problem cannot be observed. Example: HTTPS is down for a site, but the FR can access the site through HTTPS without incident.
# The trigger resolved itself and the problem can still be observed.
# The trigger is still firing but the problem cannot be observed: Our triggers might not be perfect, so it could be that something else is causing it to fire. A simple example would be that Zabbix reports that the the DNS for a site can't be resolved, but in reality there's a bug in the script we wrote that checks if the DNS resolves and the DNS resolves fine. Final note: keep in mind that an 'it works on my machine' does not necessarily mean it works for most other people, so depening on the trigger you need to do some evaluations if your tests suffice.

In order to make sure you are actually trying to observe the same thing as the trigger is looking for, make sure to check the trigger definition and the current data of the associated item(s). Some triggers might fire if one of multiple conditions is met (Such as a trigger that monitors the ping response time firing if the value exceeds a certain threshold, or if no data for a certain period of time was observed).

Make sure to report your findings in the incident's thread. It's advised to post a screenshot of the relevant item(s) and your own observations. (Continuing the ping example, you would post a screenshot of the relevant values, state your conclusion why the trigger is firing, and your own observations/pings)

==== Communicate to affected clients ====
If the incident is still ongoing and the service is down, we need to communicate to affected clients that we are aware of the problem and that we are investigating it. This is because critical incident usually mean the service is down, something the clients can notice/are affected by, so we to be transparent that something is going on. There are some additional notes to this though:
* If an incident has already resolved itself and the problem is no longer observable, we don't communicate anything. Doing so might only cause confusion, and since the client has not reported any issues, they have not had a noticeable problem with it themselves.
* Although a critical incident generally means that the client service is down or experiencing reduced service, not all critical incidents are of that nature. Some are more administrative, or are only an issue for Delft Solutions itself. As of writing I don't have an exhaustive list, but here is those I can think of:
** SSH Service is down: We don't have any clients that SSH into their services, so it's generally not a problem. But SSH is mostly used for SRE maintenance and publishing new builds. The SRE maintenance is an internal problem, so no need to communicate to the client. The publishing is done to Kaboom, preventing new builds from being published, and the two SM VM's.
** No backup for x days: Clients don't notice it if a backup is running late, so no need to communicate with clients. Just need to make sure the backup gets completed
** SSL certificate is expiring in < 24 hours: This is a bit dependent on how soon this incident is being handled, but if it handled quickly, the certificate never actually expired, and there has not been any disruption to the client's service, so no need for communicating about it.
* Determining which clients are being affected can be done by looking at the host's DNS in the trigger, and/or looking up the VM in Proxmox and checking the tags of the VM's for client names. In the case that this issue is causing multiple other critical triggers to fire, you would have to check for which clients are affected by those incidents.
* Communicating to DS about ongoing incidents is usually assumed to be automaticly have been done by the fact that the incident was reported on Zulip.

As always, report the decisions taken and actions maded in the incident thread. (e.g.: I've sent a message in the Slack to let Kaboom know that we aware of problem x, and that we are investigating it)

==== Communicate plan/next steps + Communicate findings/results of executed plan ====
This is the main part of handling an incident. There are several actions you can take in these steps, but at the basis they consist of sharing your next steps, performing those, and reporting the results. The reason all this needs to be reported is to ensure that all known information about a problem is logged, making it easier for someone else to be onboarded into the issue, for later reference if a similar issue is encountered, and even for use during the incident itself in case an older configuration needs to be referenced after you changed it.
The objective from these steps is determining what is actually wrong and how to resolve it. Depending on the observations made earlier on whether the incident is still ongoing and is (still) observable your investigation can go into different directions. (e.g. Find the underlying cause for a trigger, or determining why the trigger is firing while it likely shouldn't, and then how to resolve that underlying cause or how to update the trigger to work better)

There are three main types of steps defined, but you are not limited to these:
# Hypothesis: If you have an idea what could be causing it, you would state your hypothesis and your next step would be to prove that hypothesis. For example, for an incident 'SSH service is down on X' your hypothesis could be that this is due to 'MaxStartups' throttling, which can be proven by 'grep'ing journalctl for that, and compare the start and end times of throttling with the timestamps of the item reporting the status of the SSH service.
# Information gathering: Sometimes it just helps to get some facts about the situation collected. What is usefull information that is relevant depends on the triggers, but some examples are: The syslog/journalctl of the host from around the time of the incident (it can contain a reference to the an underlying problem in various levels of explicitness), the ping response from several hosts on the route to a host or a traceroute (this helps with networking issues). The gathered information is usually intended to help you come up with an hypothesis on what's wrong.
# Investigative: The most rigorous of process. The full process is described here originally [https://docs.google.com/document/d/1AQYJM1Q9l2Tyk6zfCVaQ2aEq-dpbfUH5okE88bpKkhw/edit#heading=h.5fq2skijqbdc Drive - Final Coundown - General Investigative Process]. To summarize, when you don't know why something is failing, and/or don't have any decent hypotheses to follow up, you can follow this process to systematicly find the problem.

Regarding the resolution to an incident: The resolution to any incident is usually one of two things:
# Fix the underlying problem.
# Fix the trigger itself.
Fixing the trigger is relavively straightforward, but do make sure document in the thread what you changed to which trigger.
Fixing the underlying problem can be more complex. A trade-off needs to be made sometimes between resolving technical debt, or simply patching the current system to resolve the issue. We usually look for a resolution that ensures that the problem won't re-occur soon, or makes it unexpected/unlikely for the problem to re-occur. Taking into account the timeframe that is available to resolve the incident you can make some trade-offs. An example would be: normal backups of VM's are failing due to the Proxmox backup server being down/unreachable and it is determined that this cannot be resolved at that moment. We can set up automatic backups to local storage temporary to resolve the immediate problem and ensure we keep our SLO's versus setting up a new Proxmox Backup server at a different location. Since we don't have much time to resolve the problem, the resolution would be to set up the automatic backups to local storage, and set up a new Proxmox Backup Server later as a seperate issue.

===== Some known issues and their resolutions =====
* SSH service is down: The internet is a vile place. There's constant port scanning and hacking attempts ongoing to any machine connected to the internet (mostly IPv4). Due to this, SSH has a throttling functionality build in to prevent a system from being DDOS'ed by the amount of malicious SSH requests. This throttling can cause the Zabbix server from being denied an SSH connection, of which several failures fire this trigger. This hypothesis can be proven with a `journalctl -u ssh | grep 'MaxStartupsThrottling'` (you probably want to select a relevant time period with `--since "2 hours ago"` or something similar to prevent having to process a month of logging). You can then compare the throttling start and end times with the timestamps of the item data itself. The resolution for the issue is to add our custom ssh configuration [https://chat.dsinternal.net/#narrow/stream/23-SRE---General/topic/DS.20Whitelisted.20Custom.20SSH.20configuration/near/1620 Custom SSH Configuration].
* No backup for 3 days: Are S3 backup is very slow. Not much to prove as an underlying issue here. What needs to be done is check that the backup process is ongoing. The Zabbix latest data can be checked to verify that backups are running by checking that that days backups were done for the smaller buckets. The devteam email can be checked for if the backup process could not start on day due to it already running (it takes 24+ hours, and an attempt to start it is done each day by cron).
* git.* HTTPS is down: On Sunday mostly, Gitlab gets automaticly updated, but this incurs some downtime as the service is restarted. This is usually short enough to not be reported to Zulip as per our settings, but sometimes it's longer. If the service does not stay down, the issue can be just resolved.

==== Resolve incident + cleanup ====
When you've executed and verified the resolution in the previous steps we can proceed resolving the issue in our Mattermost integration. Resolving an incident can be done by doing the following:
# Verify that the trigger is no longer firing. An incident will be immediatly re-opened if the trigger is still firing, and the incident cannot be considered resolved if the trigger is still firing. If the trigger is still firing but you're sure that you've resolved the problem, you might need to force the item the trigger depends on to update. This can be done by finding the item in the host's configuration on Zabbix and selecting 'Execute Now', after a short period this should force Zabbix to re-execute the item. You can check the timestamps in the latest data of an item to check if it was updated.
# Close the incident by marking the topic as resolved, when there are no other triggers firing for the host.

Unfortunatly, some problems cause multiple critical and non-critical triggers to fire. This means we have to check Zabbix and Zulip for other fired triggers and ongoing incidents. The goal is to identify critical and non-critical incidents that were caused by the incident/underlying issue you just resolved.
# First, these incidents need to be acknowledged on Zabbix, and in the acknowledgement message you mention the incident/problem that caused this.
# Next, check the incident tracked by the integration on Mattermost using the `?ongoing` command. Resolve incidents that were (re-)opened by this incident by executing the following steps. If the first two fail (problem still persists, trigger is still firing), the incident needs to considered it's own issue and the relevant process needs to be followed (critical or non-critical depending on criticality).
## Ensuring the mentioned problem is no longer observable
## The trigger has resolved (You might need to force an update with `Execute Now`).
## Posting a link to the main incident you resolved with the comment that the underlying problem was resolved in that topic.
## Closing the incident by marking the topic as resolved, when there are no other triggers firing for the host.

When you are done, there should be no more critical triggers firing in Zabbix or open in the Zabbix-Mattermost intergration, for which no-one has taken responsibility or you have taken responsibility for and are not actively handling.

===Additional context===
* Critical incidents are posted in [https://chat.dsinternal.net/#narrow/stream/24-SRE-.23-Critical '''SLA - Critical'''].
* <s>When it is being tracked on GitLab a heavy check mark is added to the message.</s>
* <s>Responses on the thread and on GitLab are automatically synced (to some extend)</s>
* <s>When you reply with '''I agree that this has been fully resolved''' eventually our Zabbix-Mattermost integration will pick this up and a green check mark is added to the message.</s>

== Non-Critical incidents ==
* Non-critical incidents are acknowledged within 9 hours and resolved within one week.

=== Acknowledging ===
Fully acknowledging a non-critical incident requires the following tasks to have been completed:
* Acknowledging the incident on Zabbix, which means you take responsibility of completing the steps listed below.

The next steps don't have to be done immediatly, as they have dependencies, but be started and scheduled for completion the next work day.

Check if there's already a uncompleted milestone for this host with this issue in the metrics sheet.
If a milestone is already present:
* Report in the topic the Lynx project ID for resolving this issue.
* If the ID has already been reported in the topic, we don't want to report it again and again, instead add the 🔁 emoji (:repeat:) under the zabbix bot alert

If a milestone is NOT already present:
* Add the non-critical incident as a milestone in the metrics sheet, following the naming convention
** Start date is the date of the incident
** DoD states what needs to be true for the non-critical incident to be consider resolved
* Add the non-critical incident to Lynx as a project
** Follow the naming convention below for the title & project ID
** Tasks need to be added
** Final tasks needs to have the SLO deadline set as 'contraint'
** Project priority is set to 99 while not estimated yet. After the estimation is done, the priority should be set to 20
** The tasks are estimated for SP
* The Lynx project ID is reported in the non-critical incident's topic on Zulip, and logged in the metrics sheet
* A Kimai activity is created in Kimai for the non-critical incident, following the naming convetion

==== Naming convention ====
* Kimai activity name needs to follow the pattern: '<YYYY-MM> <problem_title>'. For <problem_title>, incorporate the trigger title and hostname for clarity.
* Milestone name needs to follow the pattern: 'Delft Solutions Hosting Incident response work <kimai_activity_name>'
* Lynx project name needs to follow the pattern: 'Delft Solutions Hosting Incident response work <kimai_activity_name>'
* Lynx project ID needs to follow the pattern: 'SRE<YYMM><XXX>', where <XXX> is some three letter shorthand that relates to the problem/host

== Informational incidents ==
* Informational incidents are acknowledged within 72 hours

Checklist
# Acknowledge on Zabbix
# Sanity check the event, post result in thread
# If action needed, perform action

== If an incident is reported by other means than the Zabbix-Zulip intergration ==
# Acknowledge receipt.
# Classify the incident as critical, non-critical, or informational.
# Create an topic in the relevant SRE channel, stating the problem and that you is responsible for resolving it.
# Proceed to treat the incident according to the criticality you just classified it as. (So for a critical incident, it means you now start the critical incident handling process)

== Handover ==
When handing over the responsibility of '''first responder''' (FR), the following needs to happen:
* The handover can be initiated by both the upcoming FR or the acting FR
* Acting FR adds the upcoming FR the the IPA sla-first-responder user group and enables Zabbix calling for that the upcoming FR if they have that set by going to Zabbix > Configuration > Actions > [https://status.delftinfra.net/zabbix/actionconf.php?eventsource=0# Trigger actions]
* The upcoming FR makes sure they are aware of the state of the SLA and knows what questions they wants to ask the acting FR.
* The upcoming FR makes sure they are subscribed to the right channels.

The following steps can be done async or in person:
* The acting FR announces/informs the upcoming FR has been added to the sla-first-responder group (In Zulip's [https://chat.dsinternal.net/#narrow/stream/13-Organisational Organisational channel] if asynq).
* If the acting FR wants to hand over responsibility for any ongoing incident they also state which incidents they want the upcoming FR to take over.
* If there are any particularities the upcoming FR needs to be aware of, those are shared.
* The upcoming FR asks their questions until they are satisfied and able to take over the FR
* The upcoming FR ensures they are subscribed to the following channels on Zulip: [https://chat.dsinternal.net/#narrow/stream/23-SRE---General SRE - General], [https://chat.dsinternal.net/#narrow/stream/24-SRE-.23-Critical SRE # Critical] and if part of the SRE team [https://chat.dsinternal.net/#streams/4/SRE%20##%20Non-critical SRE ## Non-Critical] and [https://chat.dsinternal.net/#streams/5/SRE%20###%20Informational SRE ### Informational].
* The upcoming FR announces/informs that they are now the acting FR over Zulip's [https://chat.dsinternal.net/#narrow/stream/13-Organisational Organisational channel]
* The now acting FR removes the previous FR from IPA the sla-first-responder user group and disables Zabbix calling for the previous FR if they had that enabled by going to Zabbix > Configuration > Actions > [https://status.delftinfra.net/zabbix/actionconf.php?eventsource=0# Trigger actions]

New receipt

2024-12-04T14:47:43Z

Dortund:

# Log into Exact
# Go to “Purchase” > “Entries” > “Create”
# Click “60 - Inkoopboek”
# Add a picture of the receipt as an attachment
# Under “Supplier”, find the supplier and select the correct supplier
# Numbered list item
## If the supplier does not exist, you have to add a new supplier, but there is no guide for this
# Under “Invoice Data”
## Enter the description of what is on the receipt (e.g. enter “lunch stuff” for when you have a receipt for buying lunch stuff)
## Set the 'Payment Condition':
### IDEAL for receipst paid with ideal
### PIN for receipts paid with debit card
### One of the payment durations if it's an invoice with a certain payment term
## Enter total amount on the receipt under “Total amount”
## Update “Invoice Date” (And probably also “Due date”) to match the date on the receipt
# Make sure the expenses are for the correct G/L Account, e.g. lunch/borrel stuff should be under 4012
# Make sure the VAT code is correct, as well as the VAT amount
## For receipts for food stuffs (lunch, drinks, diner, etc.), the VAT code needs to be `0` (`Geen BTW`), despite the fact that the receipt may state VAT
# Click “Save + new”
# Ask Wouter to reconcile the payment+receipt
# Done

Incident Handling

2024-11-22T15:07:26Z

Dortund:

== Zulip migration ==
Due to a migration to Zulip, the integration as was available on Mattermost is not available yet on Zulip. This leads to the following process changes:
* Acknowlegements and triggers resolving are not posted to Zulip by Zabbix
* Triggers are grouped in a topic on Zulip per host
* When an incident has been fully resolved, mark the topic as resolved, when any other incidents reported for the host are resolved
* There's no `?ongoing`, instead for now we can track open incidents by checking for unresolved topics
* The posting of incidents is less smart (only posting when not posted yet), so in order to prevent an incident from not being reported due to network issues or the likes, a message is posted after an inteval (8 hours for non-critical and lower, 1 hour for critical and above) while the incident has not been acknowleged.
* Incidents can be manually tracked by creating a topic by hand and reporting the problem.
* There is no automatic gitlab issue creation or syncing anymore.

Finally, where this process says to do something on Mattermost, you should now do so on Zulip. The updates in the process chapters themselves are WIP.

== Critical incidents ==
'''Critical incidents are resolved within 16 hours.'''

As first responder you take on the responsiblity of seeing an incident resolved. This does not mean that you are the person required to do all the work. You can attempt to involve other to help you (often referred to as escalating the incident), but since other are not on-call, they are not obliged to help you, especially outside of normal working hours.
Involving multiple people can quickly be required if multiple critical incidents with different causes occur simultaniously. In that case, the First Responder usually takes on a more information management role and steers those that are brought on into resolving the issues. (Example: if a server crashes, several critical triggers can fire, but the underlying cause can quite quickly be determined to be a single issue, the crashed server. So you wouldn't need to call in people to manage each incident. But a client's service being down in one cluster while in a different cluster a different VM no longer boots is likely to be to different issues, so in order to resolve them on time you'd want to call in help to resolve the incident in time).

=== Process ===
The general process is made up of the folowing steps. Each step has additional information on how to handle/execute them in the sections below.
# Take responsibility for seeing the incident resolved
# Determine if incident is still ongoing
# If ongoing: Communicate to affected clients that the issue is being investigated
# Communicate plan/next steps (even if that is gathering information)
# Communicate findings/results of executed plan, go back to previous step if not resolved
# Resolve incident + cleanup

During working on an incident it is expected that all communication is done in the incident's thread. This means all information to a problem can be found in a clear a predictable place. Sometimes an incident can be resolved by work done in another incident. In that case, it is required to post a link to that thread in the incident's thread with the comment that the resolution is done in that thread.

==== Acknowledge the incident on Zabbix ====
The first step is to take responsibility for seeing the incident resolved by acknowledging the incident on Zabbix. Simply acknowledging the trigger suffices. It is however entirely possible that multiple critical incidents are firing at the same time. This can be a coincidence, or can be because of a share cause of failure. For example, a server crashing will cause server VM' to reboot, or the router having an connectivity issue will lead to most other VM's having connectivity issues as well. If there are multiple critical incidents, it is advised to quickly observe what's ongoing, Zabbix is the best source of firing triggers for this, and pick the incident that is likely the root cause to

* Acknowledging an incident on Zabbix will stop Zabbix from calling the First Responder to notify them of the ongoing incident. And stops Zabbix from posting reminders on Zulip.

==== Determine if incident is still ongoing ====
The next step is to check if the reported problem is still ongoing. Depending on the observations made here your process to follow and steps needed to resolve the incident can change. There are three options:
# The trigger resolved itself and the problem cannot be observed. Example: HTTPS is down for a site, but the FR can access the site through HTTPS without incident.
# The trigger resolved itself and the problem can still be observed.
# The trigger is still firing but the problem cannot be observed: Our triggers might not be perfect, so it could be that something else is causing it to fire. A simple example would be that Zabbix reports that the the DNS for a site can't be resolved, but in reality there's a bug in the script we wrote that checks if the DNS resolves and the DNS resolves fine. Final note: keep in mind that an 'it works on my machine' does not necessarily mean it works for most other people, so depening on the trigger you need to do some evaluations if your tests suffice.

In order to make sure you are actually trying to observe the same thing as the trigger is looking for, make sure to check the trigger definition and the current data of the associated item(s). Some triggers might fire if one of multiple conditions is met (Such as a trigger that monitors the ping response time firing if the value exceeds a certain threshold, or if no data for a certain period of time was observed).

Make sure to report your findings in the incident's thread. It's advised to post a screenshot of the relevant item(s) and your own observations. (Continuing the ping example, you would post a screenshot of the relevant values, state your conclusion why the trigger is firing, and your own observations/pings)

==== Communicate to affected clients ====
If the incident is still ongoing and the service is down, we need to communicate to affected clients that we are aware of the problem and that we are investigating it. This is because critical incident usually mean the service is down, something the clients can notice/are affected by, so we to be transparent that something is going on. There are some additional notes to this though:
* If an incident has already resolved itself and the problem is no longer observable, we don't communicate anything. Doing so might only cause confusion, and since the client has not reported any issues, they have not had a noticeable problem with it themselves.
* Although a critical incident generally means that the client service is down or experiencing reduced service, not all critical incidents are of that nature. Some are more administrative, or are only an issue for Delft Solutions itself. As of writing I don't have an exhaustive list, but here is those I can think of:
** SSH Service is down: We don't have any clients that SSH into their services, so it's generally not a problem. But SSH is mostly used for SRE maintenance and publishing new builds. The SRE maintenance is an internal problem, so no need to communicate to the client. The publishing is done to Kaboom, preventing new builds from being published, and the two SM VM's.
** No backup for x days: Clients don't notice it if a backup is running late, so no need to communicate with clients. Just need to make sure the backup gets completed
** SSL certificate is expiring in < 24 hours: This is a bit dependent on how soon this incident is being handled, but if it handled quickly, the certificate never actually expired, and there has not been any disruption to the client's service, so no need for communicating about it.
* Determining which clients are being affected can be done by looking at the host's DNS in the trigger, and/or looking up the VM in Proxmox and checking the tags of the VM's for client names. In the case that this issue is causing multiple other critical triggers to fire, you would have to check for which clients are affected by those incidents.
* Communicating to DS about ongoing incidents is usually assumed to be automaticly have been done by the fact that the incident was reported on Zulip.

As always, report the decisions taken and actions maded in the incident thread. (e.g.: I've sent a message in the Slack to let Kaboom know that we aware of problem x, and that we are investigating it)

==== Communicate plan/next steps + Communicate findings/results of executed plan ====
This is the main part of handling an incident. There are several actions you can take in these steps, but at the basis they consist of sharing your next steps, performing those, and reporting the results. The reason all this needs to be reported is to ensure that all known information about a problem is logged, making it easier for someone else to be onboarded into the issue, for later reference if a similar issue is encountered, and even for use during the incident itself in case an older configuration needs to be referenced after you changed it.
The objective from these steps is determining what is actually wrong and how to resolve it. Depending on the observations made earlier on whether the incident is still ongoing and is (still) observable your investigation can go into different directions. (e.g. Find the underlying cause for a trigger, or determining why the trigger is firing while it likely shouldn't, and then how to resolve that underlying cause or how to update the trigger to work better)

There are three main types of steps defined, but you are not limited to these:
# Hypothesis: If you have an idea what could be causing it, you would state your hypothesis and your next step would be to prove that hypothesis. For example, for an incident 'SSH service is down on X' your hypothesis could be that this is due to 'MaxStartups' throttling, which can be proven by 'grep'ing journalctl for that, and compare the start and end times of throttling with the timestamps of the item reporting the status of the SSH service.
# Information gathering: Sometimes it just helps to get some facts about the situation collected. What is usefull information that is relevant depends on the triggers, but some examples are: The syslog/journalctl of the host from around the time of the incident (it can contain a reference to the an underlying problem in various levels of explicitness), the ping response from several hosts on the route to a host or a traceroute (this helps with networking issues). The gathered information is usually intended to help you come up with an hypothesis on what's wrong.
# Investigative: The most rigorous of process. The full process is described here originally [https://docs.google.com/document/d/1AQYJM1Q9l2Tyk6zfCVaQ2aEq-dpbfUH5okE88bpKkhw/edit#heading=h.5fq2skijqbdc Drive - Final Coundown - General Investigative Process]. To summarize, when you don't know why something is failing, and/or don't have any decent hypotheses to follow up, you can follow this process to systematicly find the problem.

Regarding the resolution to an incident: The resolution to any incident is usually one of two things:
# Fix the underlying problem.
# Fix the trigger itself.
Fixing the trigger is relavively straightforward, but do make sure document in the thread what you changed to which trigger.
Fixing the underlying problem can be more complex. A trade-off needs to be made sometimes between resolving technical debt, or simply patching the current system to resolve the issue. We usually look for a resolution that ensures that the problem won't re-occur soon, or makes it unexpected/unlikely for the problem to re-occur. Taking into account the timeframe that is available to resolve the incident you can make some trade-offs. An example would be: normal backups of VM's are failing due to the Proxmox backup server being down/unreachable and it is determined that this cannot be resolved at that moment. We can set up automatic backups to local storage temporary to resolve the immediate problem and ensure we keep our SLO's versus setting up a new Proxmox Backup server at a different location. Since we don't have much time to resolve the problem, the resolution would be to set up the automatic backups to local storage, and set up a new Proxmox Backup Server later as a seperate issue.

Some know issues and their resolutions:
* SSH service is down: The internet is a vile place. There's constant port scanning and hacking attempts ongoing to any machine connected to the internet (mostly IPv4). Due to this, SSH has a throttling functionality build in to prevent a system from being DDOS'ed by the amount of malicious SSH requests. This throttling can cause the Zabbix server from being denied an SSH connection, of which several failures fire this trigger. This hypothesis can be proven with a `journalctl -u ssh | grep 'MaxStartupsThrottling'` (you probably want to select a relevant time period with `--since "2 hours ago"` or something similar to prevent having to process a month of logging). You can then compare the throttling start and end times with the timestamps of the item data itself. The resolution for the issue is to add our custom ssh configuration [https://chat.dsinternal.net/#narrow/stream/23-SRE---General/topic/DS.20Whitelisted.20Custom.20SSH.20configuration/near/1620 Custom SSH Configuration].
* No backup for 3 days: Are S3 backup is very slow. Not much to prove as an underlying issue here. What needs to be done is check that the backup process is ongoing. The Zabbix latest data can be checked to verify that backups are running by checking that that days backups were done for the smaller buckets. The devteam email can be checked for if the backup process could not start on day due to it already running (it takes 24+ hours, and an attempt to start it is done each day by cron).
* git.* HTTPS is down: On Sunday mostly, Gitlab gets automaticly updated, but this incurs some downtime as the service is restarted. This is usually short enough to not be reported to Zulip as per our settings, but sometimes it's longer. If the service does not stay down, the issue can be just resolved.

==== Resolve incident + cleanup ====
When you've executed and verified the resolution in the previous steps we can proceed resolving the issue in our Mattermost integration. Resolving an incident can be done by doing the following:
# Verify that the trigger is no longer firing. An incident will be immediatly re-opened if the trigger is still firing, and the incident cannot be considered resolved if the trigger is still firing. If the trigger is still firing but you're sure that you've resolved the problem, you might need to force the item the trigger depends on to update. This can be done by finding the item in the host's configuration on Zabbix and selecting 'Execute Now', after a short period this should force Zabbix to re-execute the item. You can check the timestamps in the latest data of an item to check if it was updated.
# Close the incident by marking the topic as resolved, when there are no other triggers firing for the host.

Unfortunatly, some problems cause multiple critical and non-critical triggers to fire. This means we have to check Zabbix and Zulip for other fired triggers and ongoing incidents. The goal is to identify critical and non-critical incidents that were caused by the incident/underlying issue you just resolved.
# First, these incidents need to be acknowledged on Zabbix, and in the acknowledgement message you mention the incident/problem that caused this.
# Next, check the incident tracked by the integration on Mattermost using the `?ongoing` command. Resolve incidents that were (re-)opened by this incident by executing the following steps. If the first two fail (problem still persists, trigger is still firing), the incident needs to considered it's own issue and the relevant process needs to be followed (critical or non-critical depending on criticality).
## Ensuring the mentioned problem is no longer observable
## The trigger has resolved (You might need to force an update with `Execute Now`).
## Posting a link to the main incident you resolved with the comment that the underlying problem was resolved in that topic.
## Closing the incident by marking the topic as resolved, when there are no other triggers firing for the host.

When you are done, there should be no more critical triggers firing in Zabbix or open in the Zabbix-Mattermost intergration, for which no-one has taken responsibility or you have taken responsibility for and are not actively handling.

===Additional context===
* Critical incidents are posted in [https://chat.dsinternal.net/#narrow/stream/24-SRE-.23-Critical '''SLA - Critical'''].
* <s>When it is being tracked on GitLab a heavy check mark is added to the message.</s>
* <s>Responses on the thread and on GitLab are automatically synced (to some extend)</s>
* <s>When you reply with '''I agree that this has been fully resolved''' eventually our Zabbix-Mattermost integration will pick this up and a green check mark is added to the message.</s>

== Non-Critical incidents ==
* Non-critical incidents are acknowledged within 9 hours and resolved within one week.

=== Acknowledging ===
Fully acknowledging a non-critical incident requires the following tasks to have been completed:
* Acknowledging the incident on Zabbix, which means you take responsibility of completing the steps listed below.

The next steps don't have to be done immediatly, as they have dependencies, but be started and scheduled for completion the next work day.

Check if there's already a uncompleted milestone for this host with this issue in the metrics sheet.
If a milestone is already present:
* Report in the topic the Lynx project ID for resolving this issue.

If a milestone is NOT already present:
* Add the non-critical incident as a milestone in the metrics sheet, following the naming convention
** Start date is the date of the incident
** DoD states what needs to be true for the non-critical incident to be consider resolved
* Add the non-critical incident to Lynx as a project
** Follow the naming convention below for the title & project ID
** Tasks need to be added
** Final tasks needs to have the SLO deadline set as 'contraint'
** Project priority is set to 99 while not estimated yet. After the estimation is done, the priority should be set to 20
** The tasks are estimated for SP
* The Lynx project ID is reported in the non-critical incident's topic on Zulip, and logged in the metrics sheet
* A Kimai activity is created in Kimai for the non-critical incident, following the naming convetion

==== Naming convention ====
* Kimai activity name needs to follow the pattern: '<YYYY-MM> <problem_title>'. For <problem_title>, incorporate the trigger title and hostname for clarity.
* Milestone name needs to follow the pattern: 'Delft Solutions Hosting Incident response work <kimai_activity_name>'
* Lynx project name needs to follow the pattern: 'Delft Solutions Hosting Incident response work <kimai_activity_name>'
* Lynx project ID needs to follow the pattern: 'SRE<YYMM><XXX>', where <XXX> is some three letter shorthand that relates to the problem/host

== Informational incidents ==
* Informational incidents are acknowledged within 72 hours

Checklist
# Acknowledge on Zabbix
# Sanity check the event, post result in thread
# If action needed, perform action

== If an incident is reported by other means than the Zabbix-Zulip intergration ==
# Acknowledge receipt.
# Classify the incident as critical, non-critical, or informational.
# Create an topic in the relevant SRE channel, stating the problem and that you is responsible for resolving it.
# Proceed to treat the incident according to the criticality you just classified it as. (So for a critical incident, it means you now start the critical incident handling process)

== Handover ==
When handing over the responsibility of '''first responder''' (FR), the following needs to happen:
* The handover can be initiated by both the upcoming FR or the acting FR
* Acting FR adds the upcoming FR the the IPA sla-first-responder user group and enables Zabbix calling for that the upcoming FR if they have that set by going to Zabbix > Configuration > Actions > [https://status.delftinfra.net/zabbix/actionconf.php?eventsource=0# Trigger actions]
* The upcoming FR makes sure they are aware of the state of the SLA and knows what questions they wants to ask the acting FR.
* The upcoming FR makes sure they are subscribed to the right channels.

The following steps can be done async or in person:
* The acting FR announces/informs the upcoming FR has been added to the sla-first-responder group (In Zulip's [https://chat.dsinternal.net/#narrow/stream/13-Organisational Organisational channel] if asynq).
* If the acting FR wants to hand over responsibility for any ongoing incident they also state which incidents they want the upcoming FR to take over.
* If there are any particularities the upcoming FR needs to be aware of, those are shared.
* The upcoming FR asks their questions until they are satisfied and able to take over the FR
* The upcoming FR ensures they are subscribed to the following channels on Zulip: [https://chat.dsinternal.net/#narrow/stream/23-SRE---General SRE - General], [https://chat.dsinternal.net/#narrow/stream/24-SRE-.23-Critical SRE # Critical] and if part of the SRE team [https://chat.dsinternal.net/#streams/4/SRE%20##%20Non-critical SRE ## Non-Critical] and [https://chat.dsinternal.net/#streams/5/SRE%20###%20Informational SRE ### Informational].
* The upcoming FR announces/informs that they are now the acting FR over Zulip's [https://chat.dsinternal.net/#narrow/stream/13-Organisational Organisational channel]
* The now acting FR removes the previous FR from IPA the sla-first-responder user group and disables Zabbix calling for the previous FR if they had that enabled by going to Zabbix > Configuration > Actions > [https://status.delftinfra.net/zabbix/actionconf.php?eventsource=0# Trigger actions]

Booking wages

2024-11-02T22:44:30Z

Dortund:

== Wage slips ==

# Exact
# Financieel > Boekingen en grootboekrekeningen > Boekingen > Aanmaken (English: Financial -> Entries & G/L Accounts -> Entries -> Create)
# Inkoop > '''80 - Salarisstroken'''
# Add file (wage slip)
# Set `Supplier` to the person this wage slip meant for
# Beschijving: Salaris periode {YEAR}-{MONTH}-M / {YEAR}-{MONTH}-M {NAME}
# Ensure `Payment condition` is set to `M - Einde volgende maand`
# Ensure `Invoice date` is set to the beginning of the month
# Totaalbedrag: Set to '''Totaal netto''' from the wage slip
# Line items:
## From the wage slip's '''Bruto > Salaris''' add the value of it as '''Bruto loon (4000)''', with description 'Salaris periode {YEAR}-{MONTH}-M / {YEAR}-{MONTH}-M {NAME}'
## From the wage slip's '''Bruto > Bonus (BT)''' if present, add the value of it as '''Te betalen bonussen (1790)''' with description 'Salaris bonus {YEAR}-{MONTH}-M / {YEAR}-{MONTH}-M {NAME}'
## From the wage slip's '''Loonheffing''' add the value of it as a negative amount as '''af te dragen loonheffing (1700)''', with description 'Salaris LH {YEAR}-{MONTH}-M / {YEAR}-{MONTH}-M {NAME}'
## From the wage slip's '''Netto > Onkostenvergoeding''' if present, add the value of it as '''Kosten nettovergoedingen'''

== Wage taxes ==
# Exact
# Financieel > Boekingen en grootboekrekeningen > Boekingen > Aanmaken
# Inkoop > '''80 - Salarisstroken'''
# Add file (LH/'Loonaangifte_Bedrijf_Overzicht_Delft_Solutions_BV_*.pdf)
# Set `Supplier` to `Belastingdienst`
# Beschrijving: Enter the value for ''LHnummer en volgnummer'' from the document
# Ensure `Payment Condition` is set to `D - Deze maand`
# Ensure `Invoice date` is set to the beginning of the month, if the 'send' date on the document is not of the current month. Otherwise, just set the 'send' date
# Set `Total amount` to the value of `Totaal Generaal` from the document
# Line items:
## From the document's '''Loonbelasting / premie volksverzekering''' add the section's total value as '''Af te dragen loonheffing (1700)''' with description `Loonbelasting / premie volksverzekering {YEAR}-{MONTH}`
## From the document's '''Premies''' add the section's total value as '''Kosten sociale premies werkgever (4041)''' with description `Premies {YEAR}-{MONTH}`

== Pension ==

# Exact
# Financieel > Boekingen en grootboekrekeningen > Boekingen > Aanmaken
# Inkoop > '''80 - Salarisstroken'''
# Add file (JP/'Journaalposten_Delft_Solutions_BV_*.pdf)
# Set `Supplier` to `Bright Pensions N.V.`
# Beschrijving: Pensioen {YEAR}-{MONTH}-M
# Ensure `Payment condition` is set to `IN - Incasso`
# Ensure `Invoice date` is set to the the '16th' of the month of the period over which the document documents the pension payments. (Look at 'Periodes' for this)
# Totaalbedrag: Set to the value of '''Pensioenafdracht WG en WN''' on the document
# Line items:
## For each person who received pension payment: '''Pensioenen (4011)''' with description `Pensioen {YEAR}-{MONTH}-M {NAME}` and with the correct value (At the moment, 1/3 of the total amount per person).

== Reconciliation (after payment) ==
# Financieel > Boekingen en grootboekrekeningen > Overzichten > Kaarten (In English: Financial > Entries & G/L Accounts > Reports > Transactions)
# Search for '''Af te dragen loonheffing (1700)'''. Ensure the relevant `Financial year` is selected.
# First, only mark (not actually match) the wage slips together with the IRS slip for wage taxes. The difference at the bottom (e.g. 0.16 EUR) needs to be added to the wage tax document.
## For line item '''Af te dragen loonheffing (1700)''' add the difference to the current value (0.16 EUR in this example)
## Create line item '''Rekenverschillen (9200)''' with description {ENTRY_DESCRIPTION} {YEAR}-{MONTH} and the value in negative (-0.16 EUR in this example)
## Mark the wage slips together with the IRS slip for wage taxes again. The difference should now be 0.
# Select `Match` at the top of the screen to match the entries.

== Reconciliation of the payment itself ==
# Go to Financial > Banking & Cash > Statements > To be completed and search for `to be completed` statements.
# Ensure the G/L account is set to `1671 - Te betalen lonen`, and the account is set to `1 - Belastingdienst`.
# Select `Match` and select the matching entry (Previously created in the `Wage Taxes` section).

== Reconciliation of the pension payments ==
# Go to Financial > Banking & Cash > Statements > To be completed and search for `to be completed` statements.
# Ensure the G/L is set to `1671 - Te betalen lonen`, and the account is set to `47 - Bring Pensions N.V.` for the three pension payments.
# Click 'Match' on any of the pension payments
# In the modal, check the checkbox for the other two pension payments, and the correct pension document entry (The one created earlier in the `Pension` section). Finally, click `Enter`.

== Preparing wage payments ==
# Create a payment scheduled on the correct date (15th of the month) for 12:00 (Midday), for each wage slip added, with the description `Salaris periode {YEAR}-{MONTH}-M {NAME}`

Incident Handling

2024-11-01T16:30:54Z

Dortund:

== Zulip migration ==
Due to a migration to Zulip, the integration as was available on Mattermost is not available yet on Zulip. This leads to the following process changes:
* Acknowlegements and triggers resolving are not posted to Zulip by Zabbix
* Triggers are grouped in a topic on Zulip per host
* When an incident has been fully resolved, mark the topic as resolved, when any other incidents reported for the host are resolved
* There's no `?ongoing`, instead for now we can track open incidents by checking for unresolved topics
* The posting of incidents is less smart (only posting when not posted yet), so in order to prevent an incident from not being reported due to network issues or the likes, a message is posted after an inteval (8 hours for non-critical and lower, 1 hour for critical and above) while the incident has not been acknowleged.
* Incidents can be manually tracked by creating a topic by hand and reporting the problem
* There is no automatic gitlab issue creation or syncing anymore.

Finally, where this process says to do something on Mattermost, you should now do so on Zulip. The updates in the process chapters themselves are WIP.

== Critical incidents ==
* Critical incidents are resolved within 16 hours.

As first responder you take on the responsiblity of seeing an incident resolved. This does not mean that you are the person required to do all the work. You can attempt to involve other to help you (often referred to as escalating the incident), but since other are not on-call, they are not obliged to help you, especially outside of normal working hours.
Involving multiple people can quickly be required if multiple critical incidents with different causes occur simultaniously. In that case, the First Responder usually takes on a more information management role and steers those that are brought on into resolving the issues. (Example: if a server crashes, several critical triggers can fire, but the underlying cause can quite quickly be determined to be a single issue, the crashed server. So you wouldn't need to call in people to manage each incident. But a client's service being down in one cluster while in a different cluster a different VM no longer boots is likely to be to different issues, so in order to resolve them on time you'd want to call in help to resolve the incident in time).

=== Process ===
The general process is made up of the folowing steps. Each step has additional information on how to handle/execute them in the sections below.
# Take responsibility for seeing the incident resolved
# Determine if incident is still ongoing
# If ongoing: Communicate to affected clients that the issue is being investigated
# Communicate plan/next steps (even if that is gathering information)
# Communicate findings/results of executed plan, go back to previous step if not resolved
# Resolve incident + cleanup

During working on an incident it is expected that all communication is done in the incident's thread. This means all information to a problem can be found in a clear a predictable place. Sometimes an incident can be resolved by work done in another incident. In that case, it is required to post a link to that thread in the incident's thread with the comment that the resolution is done in that thread.

==== Acknowledge the incident on Zabbix ====
The first step is to take responsibility for seeing the incident resolved by acknowledging the incident on Zabbix. Simply acknowledging the trigger suffices. It is however entirely possible that multiple critical incidents are firing at the same time. This can be a coincidence, or can be because of a share cause of failure. For example, a server crashing will cause server VM' to reboot, or the router having an connectivity issue will lead to most other VM's having connectivity issues as well. If there are multiple critical incidents, it is advised to quickly observe what's ongoing, Zabbix is the best source of firing triggers for this, and pick the incident that is likely the root cause to

* Acknowledging an incident on Zabbix will stop Zabbix from calling the First Responder to notify them of the ongoing incident. And stops Zabbix from posting reminders on Zulip.

==== Determine if incident is still ongoing ====
The next step is to check if the reported problem is still ongoing. Depending on the observations made here your process to follow and steps needed to resolve the incident can change. There are three options:
# The trigger resolved itself and the problem cannot be observed. Example: HTTPS is down for a site, but the FR can access the site through HTTPS without incident.
# The trigger resolved itself and the problem can still be observed.
# The trigger is still firing but the problem cannot be observed: Our triggers might not be perfect, so it could be that something else is causing it to fire. A simple example would be that Zabbix reports that the the DNS for a site can't be resolved, but in reality there's a bug in the script we wrote that checks if the DNS resolves and the DNS resolves fine. Final note: keep in mind that an 'it works on my machine' does not necessarily mean it works for most other people, so depening on the trigger you need to do some evaluations if your tests suffice.

In order to make sure you are actually trying to observe the same thing as the trigger is looking for, make sure to check the trigger definition and the current data of the associated item(s). Some triggers might fire if one of multiple conditions is met (Such as a trigger that monitors the ping response time firing if the value exceeds a certain threshold, or if no data for a certain period of time was observed).

Make sure to report your findings in the incident's thread. It's advised to post a screenshot of the relevant item(s) and your own observations. (Continuing the ping example, you would post a screenshot of the relevant values, state your conclusion why the trigger is firing, and your own observations/pings)

==== Communicate to affected clients ====
If the incident is still ongoing and the service is down, we need to communicate to affected clients that we are aware of the problem and that we are investigating it. This is because critical incident usually mean the service is down, something the clients can notice/are affected by, so we to be transparent that something is going on. There are some additional notes to this though:
* If an incident has already resolved itself and the problem is no longer observable, we don't communicate anything. Doing so might only cause confusion, and since the client has not reported any issues, they have not had a noticeable problem with it themselves.
* Although a critical incident generally means that the client service is down or experiencing reduced service, not all critical incidents are of that nature. Some are more administrative, or are only an issue for Delft Solutions itself. As of writing I don't have an exhaustive list, but here is those I can think of:
** SSH Service is down: We don't have any clients that SSH into their services, so it's generally not a problem. But SSH is mostly used for SRE maintenance and publishing new builds. The SRE maintenance is an internal problem, so no need to communicate to the client. The publishing is done to Kaboom, preventing new builds from being published, and the two SM VM's.
** No backup for x days: Clients don't notice it if a backup is running late, so no need to communicate with clients. Just need to make sure the backup gets completed
** SSL certificate is expiring in < 24 hours: This is a bit dependent on how soon this incident is being handled, but if it handled quickly, the certificate never actually expired, and there has not been any disruption to the client's service, so no need for communicating about it.
* Determining which clients are being affected can be done by looking at the host's DNS in the trigger, and/or looking up the VM in Proxmox and checking the tags of the VM's for client names. In the case that this issue is causing multiple other critical triggers to fire, you would have to check for which clients are affected by those incidents.
* Communicating to DS about ongoing incidents is usually assumed to be automaticly have been done by the fact that the incident was reported on Zulip.

As always, report the decisions taken and actions maded in the incident thread. (e.g.: I've sent a message in the Slack to let Kaboom know that we aware of problem x, and that we are investigating it)

==== Communicate plan/next steps + Communicate findings/results of executed plan ====
This is the main part of handling an incident. There are several actions you can take in these steps, but at the basis they consist of sharing your next steps, performing those, and reporting the results. The reason all this needs to be reported is to ensure that all known information about a problem is logged, making it easier for someone else to be onboarded into the issue, for later reference if a similar issue is encountered, and even for use during the incident itself in case an older configuration needs to be referenced after you changed it.
The objective from these steps is determining what is actually wrong and how to resolve it. Depending on the observations made earlier on whether the incident is still ongoing and is (still) observable your investigation can go into different directions. (e.g. Find the underlying cause for a trigger, or determining why the trigger is firing while it likely shouldn't, and then how to resolve that underlying cause or how to update the trigger to work better)

There are three main types of steps defined, but you are not limited to these:
# Hypothesis: If you have an idea what could be causing it, you would state your hypothesis and your next step would be to prove that hypothesis. For example, for an incident 'SSH service is down on X' your hypothesis could be that this is due to 'MaxStartups' throttling, which can be proven by 'grep'ing journalctl for that, and compare the start and end times of throttling with the timestamps of the item reporting the status of the SSH service.
# Information gathering: Sometimes it just helps to get some facts about the situation collected. What is usefull information that is relevant depends on the triggers, but some examples are: The syslog/journalctl of the host from around the time of the incident (it can contain a reference to the an underlying problem in various levels of explicitness), the ping response from several hosts on the route to a host or a traceroute (this helps with networking issues). The gathered information is usually intended to help you come up with an hypothesis on what's wrong.
# Investigative: The most rigorous of process. The full process is described here originally [https://docs.google.com/document/d/1AQYJM1Q9l2Tyk6zfCVaQ2aEq-dpbfUH5okE88bpKkhw/edit#heading=h.5fq2skijqbdc Drive - Final Coundown - General Investigative Process]. To summarize, when you don't know why something is failing, and/or don't have any decent hypotheses to follow up, you can follow this process to systematicly find the problem.

Regarding the resolution to an incident: The resolution to any incident is usually one of two things:
# Fix the underlying problem.
# Fix the trigger itself.
Fixing the trigger is relavively straightforward, but do make sure document in the thread what you changed to which trigger.
Fixing the underlying problem can be more complex. A trade-off needs to be made sometimes between resolving technical debt, or simply patching the current system to resolve the issue. We usually look for a resolution that ensures that the problem won't re-occur soon, or makes it unexpected/unlikely for the problem to re-occur. Taking into account the timeframe that is available to resolve the incident you can make some trade-offs. An example would be: normal backups of VM's are failing due to the Proxmox backup server being down/unreachable and it is determined that this cannot be resolved at that moment. We can set up automatic backups to local storage temporary to resolve the immediate problem and ensure we keep our SLO's versus setting up a new Proxmox Backup server at a different location. Since we don't have much time to resolve the problem, the resolution would be to set up the automatic backups to local storage, and set up a new Proxmox Backup Server later as a seperate issue.

Some know issues and their resolutions:
* SSH service is down: The internet is a vile place. There's constant port scanning and hacking attempts ongoing to any machine connected to the internet (mostly IPv4). Due to this, SSH has a throttling functionality build in to prevent a system from being DDOS'ed by the amount of malicious SSH requests. This throttling can cause the Zabbix server from being denied an SSH connection, of which several failures fire this trigger. This hypothesis can be proven with a `journalctl -u ssh | grep 'MaxStartupsThrottling'` (you probably want to select a relevant time period with `--since "2 hours ago"` or something similar to prevent having to process a month of logging). You can then compare the throttling start and end times with the timestamps of the item data itself. The resolution for the issue is to add our custom ssh configuration [https://chat.dsinternal.net/#narrow/stream/23-SRE---General/topic/DS.20Whitelisted.20Custom.20SSH.20configuration/near/1620 Custom SSH Configuration].
* No backup for 3 days: Are S3 backup is very slow. Not much to prove as an underlying issue here. What needs to be done is check that the backup process is ongoing. The Zabbix latest data can be checked to verify that backups are running by checking that that days backups were done for the smaller buckets. The devteam email can be checked for if the backup process could not start on day due to it already running (it takes 24+ hours, and an attempt to start it is done each day by cron).
* git.* HTTPS is down: On Sunday mostly, Gitlab gets automaticly updated, but this incurs some downtime as the service is restarted. This is usually short enough to not be reported to Zulip as per our settings, but sometimes it's longer. If the service does not stay down, the issue can be just resolved.

==== Resolve incident + cleanup ====
When you've executed and verified the resolution in the previous steps we can proceed resolving the issue in our Mattermost integration. Resolving an incident can be done by doing the following:
# Verify that the trigger is no longer firing. An incident will be immediatly re-opened if the trigger is still firing, and the incident cannot be considered resolved if the trigger is still firing. If the trigger is still firing but you're sure that you've resolved the problem, you might need to force the item the trigger depends on to update. This can be done by finding the item in the host's configuration on Zabbix and selecting 'Execute Now', after a short period this should force Zabbix to re-execute the item. You can check the timestamps in the latest data of an item to check if it was updated.
# Close the incident by marking the topic as resolved, when there are no other triggers firing for the host.

Unfortunatly, some problems cause multiple critical and non-critical triggers to fire. This means we have to check Zabbix and Zulip for other fired triggers and ongoing incidents. The goal is to identify critical and non-critical incidents that were caused by the incident/underlying issue you just resolved.
# First, these incidents need to be acknowledged on Zabbix, and in the acknowledgement message you mention the incident/problem that caused this.
# Next, check the incident tracked by the integration on Mattermost using the `?ongoing` command. Resolve incidents that were (re-)opened by this incident by executing the following steps. If the first two fail (problem still persists, trigger is still firing), the incident needs to considered it's own issue and the relevant process needs to be followed (critical or non-critical depending on criticality).
## Ensuring the mentioned problem is no longer observable
## The trigger has resolved (You might need to force an update with `Execute Now`).
## Posting a link to the main incident you resolved with the comment that the underlying problem was resolved in that topic.
## Closing the incident by marking the topic as resolved, when there are no other triggers firing for the host.

When you are done, there should be no more critical triggers firing in Zabbix or open in the Zabbix-Mattermost intergration, for which no-one has taken responsibility or you have taken responsibility for and are not actively handling.

===Additional context===
* Critical incidents are posted in [https://chat.dsinternal.net/#narrow/stream/24-SRE-.23-Critical '''SLA - Critical'''].
* <s>When it is being tracked on GitLab a heavy check mark is added to the message.</s>
* <s>Responses on the thread and on GitLab are automatically synced (to some extend)</s>
* <s>When you reply with '''I agree that this has been fully resolved''' eventually our Zabbix-Mattermost integration will pick this up and a green check mark is added to the message.</s>

== Non-Critical incidents ==
* Non-critical incidents are acknowledged within 9 hours and resolved within one week.

=== Acknowledging ===
Fully acknowledging a non-critical incident requires the following tasks to have been completed:
* Acknowledging the incident on Zabbix
* Add the non-critical incident as a milestone in the metrics sheet
** Start date is the date of the incident
** DoD states what needs to be true for the non-critical incident to be consider resolved
* Add the non-critical incident to Lynx as a project
** Tasks need to be added
** Final tasks needs to have the SLO deadline set as 'contraint'
** Project priority is set to 20 (as a default)
** The tasks are estimated for SP
* The Lynx project ID is reported in the non-critical incident's topic on Zulip
* A Kimai activity is created in Kimai for the non-critical incident

Checklist (outdated)
# Acknowledge on Zabbix and state who is responsible for resolving this in the description
# Communicate plan/next steps (even if that is gathering information)
# Communicate findings/results of executed plan, go back to previous step if not resolved
# If there is no resolution to the incident, evaluate if the trigger needs updating/disabling
# Resolve incident

== Informational incidents ==
* Informational incidents are acknowledged within 72 hours

Checklist
# Acknowledge on Zabbix
# Sanity check the event, post result in thread
# If action needed, perform action

== If an incident is reported by other means than the Zabbix-Zulip intergration ==
# Acknowledge receipt.
# Classify the incident as critical, non-critical, or informational.
# Create an topic in the relevant SRE channel, stating the problem and that you is responsible for resolving it.
# Proceed to treat the incident according to the criticality you just classified it as. (So for a critical incident, it means you now start the critical incident handling process)

== Handover ==
When handing over the responsibility of '''first responder''' (FR), the following needs to happen:
* The handover can be initiated by both the upcoming FR or the acting FR
* Acting FR adds the upcoming FR the the IPA sla-first-responder user group and enables Zabbix calling for that the upcoming FR if they have that set by going to Zabbix > Configuration > Actions > [https://status.delftinfra.net/zabbix/actionconf.php?eventsource=0# Trigger actions]
* The upcoming FR makes sure they are aware of the state of the SLA and knows what questions they wants to ask the acting FR.
* The upcoming FR makes sure they are subscribed to the right channels

The following steps can be done async or in person:
* The acting FR announces/informs the upcoming FR has been added to the sla-first-responder group (In Zulip's [https://chat.dsinternal.net/#narrow/stream/13-Organisational Organisational channel] if asynq).
* If the acting FR wants to hand over responsibility for any ongoing incident they also state which incidents they want the upcoming FR to take over.
* If there are any particularities the upcoming FR needs to be aware of, those are shared.
* The upcoming FR asks their questions until they are satisfied and able to take over the FR
* The upcoming FR ensures they are subscribed to the following channels on Zulip: [https://chat.dsinternal.net/#narrow/stream/23-SRE---General SRE - General], [https://chat.dsinternal.net/#narrow/stream/24-SRE-.23-Critical SRE # Critical] and if part of the SRE team [https://chat.dsinternal.net/#streams/4/SRE%20##%20Non-critical SRE ## Non-Critical] and [https://chat.dsinternal.net/#streams/5/SRE%20###%20Informational SRE ### Informational].
* The upcoming FR announces/informs that they are now the acting FR over Zulip's [https://chat.dsinternal.net/#narrow/stream/13-Organisational Organisational channel]
* The now acting FR removes the previous FR from IPA the sla-first-responder user group and disables Zabbix calling for the previous FR if they had that enabled by going to Zabbix > Configuration > Actions > [https://status.delftinfra.net/zabbix/actionconf.php?eventsource=0# Trigger actions]

Incident Handling

2024-10-04T11:54:02Z

Dortund:

== Zulip migration ==
Due to a migration to Zulip, the integration as was available on Mattermost is not available yet on Zulip. This leads to the following process changes:
* Acknowlegements and triggers resolving are not posted to Zulip by Zabbix
* Triggers are grouped in a topic on Zulip per host
* When an incident has been fully resolved, mark the topic as resolved, when any other incidents reported for the host are resolved
* There's no `?ongoing`, instead for now we can track open incidents by checking for unresolved topics
* The posting of incidents is less smart (only posting when not posted yet), so in order to prevent an incident from not being reported due to network issues or the likes, a message is posted after an inteval (8 hours for non-critical and lower, 1 hour for critical and above) while the incident has not been acknowleged.
* Incidents can be manually tracked by creating a topic by hand and reporting the problem
* There is no automatic gitlab issue creation or syncing anymore.

Finally, where this process says to do something on Mattermost, you should now do so on Zulip. The updates in the process chapters themselves are WIP.

== Critical incidents ==
* Critical incidents are resolved within 16 hours.

As first responder you take on the responsiblity of seeing an incident resolved. This does not mean that you are the person required to do all the work. You can attempt to involve other to help you (often referred to as escalating the incident), but since other are not on-call, they are not obliged to help you, especially outside of normal working hours.
Involving multiple people can quickly be required if multiple critical incidents with different causes occur simultaniously. In that case, the First Responder usually takes on a more information management role and steers those that are brought on into resolving the issues. (Example: if a server crashes, several critical triggers can fire, but the underlying cause can quite quickly be determined to be a single issue, the crashed server. So you wouldn't need to call in people to manage each incident. But a client's service being down in one cluster while in a different cluster a different VM no longer boots is likely to be to different issues, so in order to resolve them on time you'd want to call in help to resolve the incident in time).

=== Process ===
The general process is made up of the folowing steps. Each step has additional information on how to handle/execute them in the sections below.
# Take responsibility for seeing the incident resolved
# Determine if incident is still ongoing
# If ongoing: Communicate to affected clients that the issue is being investigated
# Communicate plan/next steps (even if that is gathering information)
# Communicate findings/results of executed plan, go back to previous step if not resolved
# Resolve incident + cleanup

During working on an incident it is expected that all communication is done in the incident's thread. This means all information to a problem can be found in a clear a predictable place. Sometimes an incident can be resolved by work done in another incident. In that case, it is required to post a link to that thread in the incident's thread with the comment that the resolution is done in that thread.

==== Acknowledge the incident on Zabbix ====
The first step is to take responsibility for seeing the incident resolved by acknowledging the incident on Zabbix. Simply acknowledging the trigger suffices. It is however entirely possible that multiple critical incidents are firing at the same time. This can be a coincidence, or can be because of a share cause of failure. For example, a server crashing will cause server VM' to reboot, or the router having an connectivity issue will lead to most other VM's having connectivity issues as well. If there are multiple critical incidents, it is advised to quickly observe what's ongoing, Zabbix is the best source of firing triggers for this, and pick the incident that is likely the root cause to

* Acknowledging an incident on Zabbix will stop Zabbix from calling the First Responder to notify them of the ongoing incident. And stops Zabbix from posting reminders on Zulip.

==== Determine if incident is still ongoing ====
The next step is to check if the reported problem is still ongoing. Depending on the observations made here your process to follow and steps needed to resolve the incident can change. There are three options:
# The trigger resolved itself and the problem cannot be observed. Example: HTTPS is down for a site, but the FR can access the site through HTTPS without incident.
# The trigger resolved itself and the problem can still be observed.
# The trigger is still firing but the problem cannot be observed: Our triggers might not be perfect, so it could be that something else is causing it to fire. A simple example would be that Zabbix reports that the the DNS for a site can't be resolved, but in reality there's a bug in the script we wrote that checks if the DNS resolves and the DNS resolves fine. Final note: keep in mind that an 'it works on my machine' does not necessarily mean it works for most other people, so depening on the trigger you need to do some evaluations if your tests suffice.

In order to make sure you are actually trying to observe the same thing as the trigger is looking for, make sure to check the trigger definition and the current data of the associated item(s). Some triggers might fire if one of multiple conditions is met (Such as a trigger that monitors the ping response time firing if the value exceeds a certain threshold, or if no data for a certain period of time was observed).

Make sure to report your findings in the incident's thread. It's advised to post a screenshot of the relevant item(s) and your own observations. (Continuing the ping example, you would post a screenshot of the relevant values, state your conclusion why the trigger is firing, and your own observations/pings)

==== Communicate to affected clients ====
If the incident is still ongoing and the service is down, we need to communicate to affected clients that we are aware of the problem and that we are investigating it. This is because critical incident usually mean the service is down, something the clients can notice/are affected by, so we to be transparent that something is going on. There are some additional notes to this though:
* If an incident has already resolved itself and the problem is no longer observable, we don't communicate anything. Doing so might only cause confusion, and since the client has not reported any issues, they have not had a noticeable problem with it themselves.
* Although a critical incident generally means that the client service is down or experiencing reduced service, not all critical incidents are of that nature. Some are more administrative, or are only an issue for Delft Solutions itself. As of writing I don't have an exhaustive list, but here is those I can think of:
** SSH Service is down: We don't have any clients that SSH into their services, so it's generally not a problem. But SSH is mostly used for SRE maintenance and publishing new builds. The SRE maintenance is an internal problem, so no need to communicate to the client. The publishing is done to Kaboom, preventing new builds from being published, and the two SM VM's.
** No backup for x days: Clients don't notice it if a backup is running late, so no need to communicate with clients. Just need to make sure the backup gets completed
** SSL certificate is expiring in < 24 hours: This is a bit dependent on how soon this incident is being handled, but if it handled quickly, the certificate never actually expired, and there has not been any disruption to the client's service, so no need for communicating about it.
* Determining which clients are being affected can be done by looking at the host's DNS in the trigger, and/or looking up the VM in Proxmox and checking the tags of the VM's for client names. In the case that this issue is causing multiple other critical triggers to fire, you would have to check for which clients are affected by those incidents.
* Communicating to DS about ongoing incidents is usually assumed to be automaticly have been done by the fact that the incident was reported on Zulip.

As always, report the decisions taken and actions maded in the incident thread. (e.g.: I've sent a message in the Slack to let Kaboom know that we aware of problem x, and that we are investigating it)

==== Communicate plan/next steps + Communicate findings/results of executed plan ====
This is the main part of handling an incident. There are several actions you can take in these steps, but at the basis they consist of sharing your next steps, performing those, and reporting the results. The reason all this needs to be reported is to ensure that all known information about a problem is logged, making it easier for someone else to be onboarded into the issue, for later reference if a similar issue is encountered, and even for use during the incident itself in case an older configuration needs to be referenced after you changed it.
The objective from these steps is determining what is actually wrong and how to resolve it. Depending on the observations made earlier on whether the incident is still ongoing and is (still) observable your investigation can go into different directions. (e.g. Find the underlying cause for a trigger, or determining why the trigger is firing while it likely shouldn't, and then how to resolve that underlying cause or how to update the trigger to work better)

There are three main types of steps defined, but you are not limited to these:
# Hypothesis: If you have an idea what could be causing it, you would state your hypothesis and your next step would be to prove that hypothesis. For example, for an incident 'SSH service is down on X' your hypothesis could be that this is due to 'MaxStartups' throttling, which can be proven by 'grep'ing journalctl for that, and compare the start and end times of throttling with the timestamps of the item reporting the status of the SSH service.
# Information gathering: Sometimes it just helps to get some facts about the situation collected. What is usefull information that is relevant depends on the triggers, but some examples are: The syslog/journalctl of the host from around the time of the incident (it can contain a reference to the an underlying problem in various levels of explicitness), the ping response from several hosts on the route to a host or a traceroute (this helps with networking issues). The gathered information is usually intended to help you come up with an hypothesis on what's wrong.
# Investigative: The most rigorous of process. The full process is described here originally [https://docs.google.com/document/d/1AQYJM1Q9l2Tyk6zfCVaQ2aEq-dpbfUH5okE88bpKkhw/edit#heading=h.5fq2skijqbdc Drive - Final Coundown - General Investigative Process]. To summarize, when you don't know why something is failing, and/or don't have any decent hypotheses to follow up, you can follow this process to systematicly find the problem.

Regarding the resolution to an incident: The resolution to any incident is usually one of two things:
# Fix the underlying problem.
# Fix the trigger itself.
Fixing the trigger is relavively straightforward, but do make sure document in the thread what you changed to which trigger.
Fixing the underlying problem can be more complex. A trade-off needs to be made sometimes between resolving technical debt, or simply patching the current system to resolve the issue. We usually look for a resolution that ensures that the problem won't re-occur soon, or makes it unexpected/unlikely for the problem to re-occur. Taking into account the timeframe that is available to resolve the incident you can make some trade-offs. An example would be: normal backups of VM's are failing due to the Proxmox backup server being down/unreachable and it is determined that this cannot be resolved at that moment. We can set up automatic backups to local storage temporary to resolve the immediate problem and ensure we keep our SLO's versus setting up a new Proxmox Backup server at a different location. Since we don't have much time to resolve the problem, the resolution would be to set up the automatic backups to local storage, and set up a new Proxmox Backup Server later as a seperate issue.

Some know issues and their resolutions:
* SSH service is down: The internet is a vile place. There's constant port scanning and hacking attempts ongoing to any machine connected to the internet (mostly IPv4). Due to this, SSH has a throttling functionality build in to prevent a system from being DDOS'ed by the amount of malicious SSH requests. This throttling can cause the Zabbix server from being denied an SSH connection, of which several failures fire this trigger. This hypothesis can be proven with a `journalctl -u ssh | grep 'MaxStartupsThrottling'` (you probably want to select a relevant time period with `--since "2 hours ago"` or something similar to prevent having to process a month of logging). You can then compare the throttling start and end times with the timestamps of the item data itself. The resolution for the issue is to add our custom ssh configuration [https://chat.dsinternal.net/#narrow/stream/23-SRE---General/topic/DS.20Whitelisted.20Custom.20SSH.20configuration/near/1620 Custom SSH Configuration].
* No backup for 3 days: Are S3 backup is very slow. Not much to prove as an underlying issue here. What needs to be done is check that the backup process is ongoing. The Zabbix latest data can be checked to verify that backups are running by checking that that days backups were done for the smaller buckets. The devteam email can be checked for if the backup process could not start on day due to it already running (it takes 24+ hours, and an attempt to start it is done each day by cron).
* git.* HTTPS is down: On Sunday mostly, Gitlab gets automaticly updated, but this incurs some downtime as the service is restarted. This is usually short enough to not be reported to Zulip as per our settings, but sometimes it's longer. If the service does not stay down, the issue can be just resolved.

==== Resolve incident + cleanup ====
When you've executed and verified the resolution in the previous steps we can proceed resolving the issue in our Mattermost integration. Resolving an incident can be done by doing the following:
# Verify that the trigger is no longer firing. An incident will be immediatly re-opened if the trigger is still firing, and the incident cannot be considered resolved if the trigger is still firing. If the trigger is still firing but you're sure that you've resolved the problem, you might need to force the item the trigger depends on to update. This can be done by finding the item in the host's configuration on Zabbix and selecting 'Execute Now', after a short period this should force Zabbix to re-execute the item. You can check the timestamps in the latest data of an item to check if it was updated.
# Close the incident by marking the topic as resolved, when there are no other triggers firing for the host.

Unfortunatly, some problems cause multiple critical and non-critical triggers to fire. This means we have to check Zabbix and Zulip for other fired triggers and ongoing incidents. The goal is to identify critical and non-critical incidents that were caused by the incident/underlying issue you just resolved.
# First, these incidents need to be acknowledged on Zabbix, and in the acknowledgement message you mention the incident/problem that caused this.
# Next, check the incident tracked by the integration on Mattermost using the `?ongoing` command. Resolve incidents that were (re-)opened by this incident by executing the following steps. If the first two fail (problem still persists, trigger is still firing), the incident needs to considered it's own issue and the relevant process needs to be followed (critical or non-critical depending on criticality).
## Ensuring the mentioned problem is no longer observable
## The trigger has resolved (You might need to force an update with `Execute Now`).
## Posting a link to the main incident you resolved with the comment that the underlying problem was resolved in that topic.
## Closing the incident by marking the topic as resolved, when there are no other triggers firing for the host.

When you are done, there should be no more critical triggers firing in Zabbix or open in the Zabbix-Mattermost intergration, for which no-one has taken responsibility or you have taken responsibility for and are not actively handling.

===Additional context===
* Critical incidents are posted in [https://chat.dsinternal.net/#narrow/stream/24-SRE-.23-Critical '''SLA - Critical'''].
* <s>When it is being tracked on GitLab a heavy check mark is added to the message.</s>
* <s>Responses on the thread and on GitLab are automatically synced (to some extend)</s>
* <s>When you reply with '''I agree that this has been fully resolved''' eventually our Zabbix-Mattermost integration will pick this up and a green check mark is added to the message.</s>

== Non-Critical incidents ==
* Non-critical incidents are acknowledged within 9 hours and resolved within one week.

=== Acknowledging ===
Fully acknowledging a non-critical incident requires the following tasks to have been completed:
* Acknowledging the incident on Zabbix
* Add the non-critical incident as a milestone in the metrics sheet
** Start date is the date of the incident
** DoD states what needs to be true for the non-critical incident to be consider resolved
* Add the non-critical incident to Lynx as a project
** Tasks need to be added
** Final tasks needs to have the SLO deadline set as 'contraint'
** Project priority is set to 20 (as a default)
** The tasks are estimated for SP
* The Lynx project ID is reported in the non-critical incident's topic on Zulip
* A Kimai activity is created in Kimai for the non-critical incident

Checklist (outdated)
# Acknowledge on Zabbix and state who is responsible for resolving this in the description
# Communicate plan/next steps (even if that is gathering information)
# Communicate findings/results of executed plan, go back to previous step if not resolved
# If there is no resolution to the incident, evaluate if the trigger needs updating/disabling
# Resolve incident

== Informational incidents ==
* Informational incidents are acknowledged within 72 hours

Checklist
# Acknowledge on Zabbix
# Sanity check the event, post result in thread
# If action needed, perform action

== If an incident is reported by other means than the Zabbix-Zulip intergration ==
# Acknowledge receipt.
# Classify the incident as critical, non-critical, or informational.
# Create an topic in the relevant SRE channel, stating the problem and that you is responsible for resolving it.
# Proceed to treat the incident according to the criticality you just classified it as. (So for a critical incident, it means you now start the critical incident handling process)

== Handover ==
When handing over the responsibility of '''first responder''' (FR), the following needs to happen:
* The handover can be initiated by both the upcoming FR or the acting FR
* Acting FR adds the upcoming FR the the IPA sla-first-responder user group (Optional: and enables Zabbix calling for that person if they have that set by going to Zabbix > Configuration > Actions > [https://status.delftinfra.net/zabbix/actionconf.php?eventsource=0# Trigger actions])
* The upcoming FR makes sure they are aware of the state of the SLA and knows what questions they wants to ask the acting FR.
* The upcoming FR makes sure they are subscribed to the right channels

The following steps can be done async or in person:
* The acting FR announces/informs the upcoming FR has been added to the sla-first-responder group (In Zulip's [https://chat.dsinternal.net/#narrow/stream/13-Organisational Organisational channel] if asynq).
* If the acting FR wants to hand over responsibility for any ongoing incident they also state which incidents they want the upcoming FR to take over.
* If there are any particularities the upcoming FR needs to be aware of, those are shared.
* The upcoming FR asks their questions until they are satisfied and able to take over the FR
* The upcoming FR ensures they are subscribed to the following channels on Zulip: [https://chat.dsinternal.net/#narrow/stream/23-SRE---General SRE - General], [https://chat.dsinternal.net/#narrow/stream/24-SRE-.23-Critical SRE # Critical] and if part of the SRE team [https://chat.dsinternal.net/#streams/4/SRE%20##%20Non-critical SRE ## Non-Critical] and [https://chat.dsinternal.net/#streams/5/SRE%20###%20Informational SRE ### Informational].
* The upcoming FR announces/informs that they are now the acting FR over Zulip's [https://chat.dsinternal.net/#narrow/stream/13-Organisational Organisational channel]
* The now acting FR removes the previous FR from IPA the sla-first-responder user group (Optional: and disables Zabbix calling for that person if they had that enabled by going to Zabbix > Configuration > Actions > [https://status.delftinfra.net/zabbix/actionconf.php?eventsource=0# Trigger actions])

Booking bonus

2024-10-02T15:15:37Z

Dortund:

== Calculating bonus ==

# Obtain the bonus calculation template from 'Money' channel
# Use steps from help tab to fill in the sheet
# Save file as '<year>-Q<quarter>-bonus.xlsx' and export as pdf
# Post pdf version of file in 'Money' channel

=== Requirements ===
Rules based on the following post: https://chat.dsinternal.net/#narrow/stream/25-Money/topic/.E2.9C.94.20Wage.20files.20request.20for.202024-07/near/10522

* Bonus PDF needs to be ready by the 2nd of the new quarter before 11:00, in order for it to be approved and sent to accountants on time.
* All receipts needs to filed and reconciled by the 2nd 11:00 of the new quarter in order for the bonus to be approved.
* The bonus sheet needs to be approved by the 6th, 22:00.
* Bonus needs to filed in Exact by the quarterly meeting, if it is approved.

== Create bonus booking on exact ==

# Exact -> Financieel -> Boeken en grootboekrekeningen -> Boekingen -> Aanmaken (English: Financial -> Entries & G/L Accounts -> Entries -> Create)
# Click '91 - Bonus verdeling'
# First line item
## Set 'Datum' to last day of the quarter you're booking the bonus for (e.g. December 31st when booking Q4 bonus)
## Set 'Grootboekrekening' to '4010 - Bijzondere beloning'
## Set 'Omschrijving' to 'Bonuskosten <year> Q<quarter>'
## Set 'Debet' to total bonus to be paid out as calculated in sheet (under 'Bonus costs')
# Line item for every employee that receives a bonus (as calculated in bonus sheet)
## Set 'Datum' to same value as first line
## Set 'Grootboekrekening' to '1790 - Te betalen bonussen'
## Set 'Omschrijving to 'Bonuskosten <year> Q<quarter> <employee name>'
## Set 'Credit' to amount of bonus for that employee (as calculated in bonus sheet)
# Line item for every owner that receives a bonus (as calculated in bonus sheet)
## Set 'Datum' to same value as first line
## Set 'Grootboekrekening' to '4010 - Bijzondere beloning'
## Set 'Omschrijving to 'Bonuskosten <year> Q<quarter> <owner name>'
## Set 'Credit' to amount of bonus for that owner (as calculated in bonus sheet)
# If at this point there is a small difference between Debet and Credit (and all entered numbers are correct), you can create a line with Grootboekrekening '9200 - Rekenverschillen' to make up for the difference
# Save the entry

== Attach bonus calc sheet to booking in Exact ==

# Exact -> Documenten -> Nieuw document (English: Exact -> Documents -> New Document)
# Subject: 'Bonus <year>-Q<quarter>'
# Categorie (Category): 'Crediteuren'
# Date: Today
# Delen (Share): Huidige administratie
# Type: Bijlage (Attachement)
# Boeking (Entry): The bonus booking for that quarter (The 4010 G/L account entry that's not for an owner)
# Attach the pdf version of the bonus calc sheet

Booking bonus

2024-10-02T15:11:23Z

Dortund:

== Calculating bonus ==

# Obtain the bonus calculation template from 'Money' channel
# Use steps from help tab to fill in the sheet
# Save file as '<year>-Q<quarter>-bonus.xlsx' and export as pdf
# Post pdf version of file in 'Money' channel

=== Requirements ===
Rules based on the following post: https://chat.dsinternal.net/#narrow/stream/25-Money/topic/.E2.9C.94.20Wage.20files.20request.20for.202024-07/near/10522

* Bonus PDF needs to be ready by the 2nd of the new quarter before 11:00, in order for it to be approved and sent to accountants on time.
* All receipts needs to filed and reconciled by the 2nd 11:00 of the new quarter in order for the bonus to be approved.
* The bonus sheet needs to be approved by the 6th, 22:00.
* Bonus needs to filed in Exact by the quarterly meeting, if it is approved.

== Create bonus booking on exact ==

# Exact -> Financieel -> Boeken en grootboekrekeningen -> Boekingen -> Aanmaken (English: Financial -> Entries & G/L Accounts -> Entries -> Create)
# Click '91 - Bonus verdeling'
# First line item
## Set 'Datum' to last day of the quarter you're booking the bonus for (e.g. December 31st when booking Q4 bonus)
## Set 'Grootboekrekening' to '4010 - Bijzondere beloning'
## Set 'Omschrijving' to 'Bonuskosten <year> Q<quarter>'
## Set 'Debet' to total bonus to be paid out as calculated in sheet (under 'Bonus costs')
# Line item for every employee that receives a bonus (as calculated in bonus sheet)
## Set 'Datum' to same value as first line
## Set 'Grootboekrekening' to '1790 - Te betalen bonussen'
## Set 'Omschrijving to 'Bonuskosten <year> Q<quarter> <employee name>'
## Set 'Credit' to amount of bonus for that employee (as calculated in bonus sheet)
# Line item for every owner that receives a bonus (as calculated in bonus sheet)
## Set 'Datum' to same value as first line
## Set 'Grootboekrekening' to '4010 - Bijzondere beloning'
## Set 'Omschrijving to 'Bonuskosten <year> Q<quarter> <owner name>'
## Set 'Credit' to amount of bonus for that owner (as calculated in bonus sheet)
# If at this point there is a small difference between Debet and Credit (and all entered numbers are correct), you can create a line with Grootboekrekening '9200 - Rekenverschillen' to make up for the difference
# Save the entry

== Attach bonus calc sheet to booking in Exact ==

# Exact
# Documenten
# Nieuw document
# Subject: 'Bonus <year>-Q<quarter>'
# Categorie: 'Crediteuren'
# Date: Today
# Delen: Huidige administratie
# Type: Bijlage
# Boeking: The bonus booking for that quarter
# Attach the pdf version of the bonus calc sheet

Booking quarterly hosting invoice

2024-10-02T14:42:35Z

Dortund:

For the quarterly hosting + additional cost invoice we receive:
# Log in on Exact.
# Go to Purchase -> Entries -> Create.
# Select '60 - Inkoopboek'.
# Add the received invoice pdf as attachement.
# Set supplier to '<redacted> (eenmanszaak)'.
# Set descripton to the invoice number.
# Set the invoice date to the 'Factuurdatum' on the invoice
# Set the total to the total of the invoice (with BTW/VAT).
# For each line item on the invoice, add a line item to the entry. For each line item, ensure the Description matches that of the line item of the invoice, and ensure VAT code is set to '4' (which should be the same as on the invoice).
## For items with 'omschrijving' 'Exact', add a line item with G/L Account 4941 (Administratiekosten), set 'Amount' to the amount + VAT from the invoice.
## For items with 'omschrijving' 'Kagi', add a line item with G/L Account 5550 (Algemene kosten), set 'Amount' to the amount + VAT from the invoice.
## For items with 'omschrijving' that matches our clients, these are our hosting fees, so add a line item with G/L Account 7010 (Kosten hosting), set 'Amount' to the amount + VAT from the invoice.
# Check that the VAT percentages of the line items match those of the line items of the invoice.
# Check that the total of the line items adds up to the total of the invoice.
# Click 'Save+new' to save.

Booking bonus

2024-10-02T11:38:43Z

Dortund:

== Calculating bonus ==

# Obtain the bonus calculation template from 'Money' channel
# Use steps from help tab to fill in the sheet
# Save file as '<year>-Q<quarter>-bonus.xlsx' and export as pdf
# Post pdf version of file in 'Money' channel

=== Requirements ===
Rules based on the following post: https://chat.dsinternal.net/#narrow/stream/25-Money/topic/.E2.9C.94.20Wage.20files.20request.20for.202024-07/near/10522

* Bonus PDF needs to be ready by the 2nd of the new quarter before 11:00, in order for it to be approved and sent to accountants on time.
* All receipts needs to filed and reconciled by the 2nd 11:00 of the new quarter in order for the bonus to be approved.
* The bonus sheet needs to be approved by the 6th, 22:00.
* Bonus needs to filed in Exact by the quarterly meeting, if it is approved.

== Create bonus booking on exact ==

# Exact -> Financieel -> Boeken en grootboekrekeningen -> Boekingen -> Aanmaken (English: Financial -> Entries & G/L Accounts -> Entries -> Create)
# Click '91 - Bonus verdeling'
# First line item
## Set 'Datum' to last day of the quarter you're booking the bonus for (e.g. December 31st when booking Q4 bonus)
## Set 'Grootboekrekening' to '4010 - Bijzondere beloning'
## Set 'Omschrijving' to 'Bonuskosten <year> Q<quarter>'
## Set 'Debet' to total bonus to be paid out as calculated in sheet (under 'Bonus costs')
# Line item for every employee that receives a bonus (as calculated in bonus sheet)
## Set 'Datum' to same value as first line
## Set 'Grootboekrekening' to '1790 - Te betalen bonussen'
## Set 'Omschrijving to 'Bonuskosten <year> Q<quarter> <employee name>'
## Set 'Credit' to amount of bonus for that employee (as calculated in bonus sheet)
# Line item for every owner that receives a bonus (as calculated in bonus sheet)
## Set 'Datum' to same value as first line
## Set 'Grootboekrekening' to '4010 - Bijzondere beloning'
## Set 'Omschrijving to 'Bonuskosten <year> Q<quarter> <owner name>'
## Set 'Credit' to amount of bonus for that owner (as calculated in bonus sheet)
# If at this point there is a small difference between Debet and Credit (and all entered numbers are correct), you can create a line with Grootboekrekening '9200 - Rekenverschillen' to make up for the difference

== Attach bonus calc sheet to booking in Exact ==

# Exact
# Documenten
# Nieuw document
# Subject: 'Bonus <year>-Q<quarter>'
# Categorie: 'Crediteuren'
# Date: Today
# Delen: Huidige administratie
# Type: Bijlage
# Boeking: The bonus booking for that quarter
# Attach the pdf version of the bonus calc sheet

Booking bonus

2024-09-19T10:41:43Z

Dortund:

== Calculating bonus ==

# Obtain the bonus calculation template from 'Money' channel
# Use steps from help tab to fill in the sheet
# Save file as '<year>-Q<quarter>-bonus.xlsx' and export as pdf
# Post pdf version of file in 'Money' channel

=== Requirements ===

* Bonus PDF needs to be ready by the 5th, in order for it to be approved and sent to accountants on time.
* Bonus needs to filed in Exact by the quarterly meeting, if it is approved.
* All receipts needs to filed and reconciled in order for the bonus to be approved.

== Create bonus booking on exact ==

# Exact -> Financieel -> Boeken en grootboekrekeningen -> Boekingen -> Aanmaken (English: Financial -> Entries & G/L Accounts -> Entries -> Create)
# Click '91 - Bonus verdeling'
# First line item
## Set 'Datum' to last day of the quarter you're booking the bonus for (e.g. December 31st when booking Q4 bonus)
## Set 'Grootboekrekening' to '4010 - Bijzondere beloning'
## Set 'Omschrijving' to 'Bonuskosten <year> Q<quarter>'
## Set 'Debet' to total bonus to be paid out as calculated in sheet (under 'Bonus costs')
# Line item for every employee that receives a bonus (as calculated in bonus sheet)
## Set 'Datum' to same value as first line
## Set 'Grootboekrekening' to '1790 - Te betalen bonussen'
## Set 'Omschrijving to 'Bonuskosten <year> Q<quarter> <employee name>'
## Set 'Credit' to amount of bonus for that employee (as calculated in bonus sheet)
# Line item for every owner that receives a bonus (as calculated in bonus sheet)
## Set 'Datum' to same value as first line
## Set 'Grootboekrekening' to '4010 - Bijzondere beloning'
## Set 'Omschrijving to 'Bonuskosten <year> Q<quarter> <owner name>'
## Set 'Credit' to amount of bonus for that owner (as calculated in bonus sheet)
# If at this point there is a small difference between Debet and Credit (and all entered numbers are correct), you can create a line with Grootboekrekening '9200 - Rekenverschillen' to make up for the difference

== Attach bonus calc sheet to booking in Exact ==

# Exact
# Documenten
# Nieuw document
# Subject: 'Bonus <year>-Q<quarter>'
# Categorie: 'Crediteuren'
# Date: Today
# Delen: Huidige administratie
# Type: Bijlage
# Boeking: The bonus booking for that quarter
# Attach the pdf version of the bonus calc sheet

Booking wages

2024-08-29T14:25:53Z

Dortund:

== Wage slips ==

# Exact
# Financieel > Boekingen en grootboekrekeningen > Boekingen > Aanmaken (English: Financial -> Entries & G/L Accounts -> Entries -> Create)
# Inkoop > '''80 - Salarisstroken'''
# Add file (wage slip)
# Set `Supplier` to the person this wage slip meant for
# Beschijving: Salaris periode {YEAR}-{MONTH}-M / {YEAR}-{MONTH}-M {NAME}
# Ensure `Payment condition` is set to `M - Einde volgende maand`
# Ensure `Invoice date` is set to the beginning of the month
# Totaalbedrag: Set to '''Totaal netto''' from the wage slip
# Line items:
## From the wage slip's '''Bruto > Salaris''' add the value of it as '''Bruto loon (4000)''', with description 'Salaris {YEAR}-{MONTH}-M / {YEAR}-{MONTH}-M {NAME}'
## From the wage slip's '''Bruto > Bonus (BT)''' if present, add the value of it as '''Te betalen bonussen (1790)''' with description 'Salaris bonus {YEAR}-{MONTH}-M / {YEAR}-{MONTH}-M {NAME}'
## From the wage slip's '''Loonheffing''' add the value of it as a negative amount as '''af te dragen loonheffing (1700)''', with description 'Salaris LH {YEAR}-{MONTH}-M / {YEAR}-{MONTH}-M {NAME}'
## From the wage slip's '''Netto > Onkostenvergoeding''' if present, add the value of it as '''Kosten nettovergoedingen'''

== Wage taxes ==
# Exact
# Financieel > Boekingen en grootboekrekeningen > Boekingen > Aanmaken
# Inkoop > '''80 - Salarisstroken'''
# Add file (LH/'Loonaangifte_Bedrijf_Overzicht_Delft_Solutions_BV_*.pdf)
# Set `Supplier` to `Belastingdienst`
# Beschrijving: Enter the value for ''LHnummer en volgnummer'' from the document
# Ensure `Payment Condition` is set to `D - Deze maand`
# Ensure `Invoice date` is set to the beginning of the month, if the 'send' date on the document is not of the current month. Otherwise, just set the 'send' date
# Set `Total amount` to the value of `Totaal Generaal` from the document
# Line items:
## From the document's '''Loonbelasting / premie volksverzekering''' add the section's total value as '''Af te dragen loonheffing (1700)''' with description `Loonbelasting / premie volksverzekering {YEAR}-{MONTH}`
## From the document's '''Premies''' add the section's total value as '''Kosten sociale premies werkgever (4041)''' with description `Premies {YEAR}-{MONTH}`

== Pension ==

# Exact
# Financieel > Boekingen en grootboekrekeningen > Boekingen > Aanmaken
# Inkoop > '''80 - Salarisstroken'''
# Add file (JP/'Journaalposten_Delft_Solutions_BV_*.pdf)
# Set `Supplier` to `Bright Pensions N.V.`
# Beschrijving: Pensioen {YEAR}-{MONTH}-M
# Ensure `Payment condition` is set to `IN - Incasso`
# Ensure `Invoice date` is set to the the '16th' of the month of the period over which the document documents the pension payments. (Look at 'Periodes' for this)
# Totaalbedrag: Set to the value of '''Pensioenafdracht WG en WN''' on the document
# Line items:
## For each person who received pension payment: '''Pensioenen (4011)''' with description `Pensioen {YEAR}-{MONTH}-M {NAME}` and with the correct value (At the moment, 1/3 of the total amount per person).

== Reconciliation (after payment) ==
# Financieel > Boekingen en grootboekrekeningen > Overzichten > Kaarten (In English: Financial > Entries & G/L Accounts > Reports > Transactions)
# Search for '''Af te dragen loonheffing (1700)'''. Ensure the relevant `Financial year` is selected.
# First, only mark (not actually match) the wage slips together with the IRS slip for wage taxes. The difference at the bottom (e.g. 0.16 EUR) needs to be added to the wage tax document.
## For line item '''Af te dragen loonheffing (1700)''' add the difference to the current value (0.16 EUR in this example)
## Create line item '''Rekenverschillen (9200)''' with description {ENTRY_DESCRIPTION} {YEAR}-{MONTH} and the value in negative (-0.16 EUR in this example)
## Mark the wage slips together with the IRS slip for wage taxes again. The difference should now be 0.
# Select `Match` at the top of the screen to match the entries.

== Reconciliation of the payment itself ==
# Go to Financial > Banking & Cash > Statements > To be completed and search for `to be completed` statements.
# Ensure the G/L account is set to `1671 - Te betalen lonen`, and the account is set to `1 - Belastingdienst`.
# Select `Match` and select the matching entry (Previously created in the `Wage Taxes` section).

== Reconciliation of the pension payments ==
# Go to Financial > Banking & Cash > Statements > To be completed and search for `to be completed` statements.
# Ensure the G/L is set to `1671 - Te betalen lonen`, and the account is set to `47 - Bring Pensions N.V.` for the three pension payments.
# Click 'Match' on any of the pension payments
# In the modal, check the checkbox for the other two pension payments, and the correct pension document entry (The one created earlier in the `Pension` section). Finally, click `Enter`.

== Preparing wage payments ==
# Create a payment scheduled on the correct date (15th of the month) for 12:00 (Midday), for each wage slip added, with the description `Salaris periode {YEAR}-{MONTH}-M {NAME}`

Ssh-fingerprints

2024-08-12T15:34:24Z

Dortund:

If the host you're ssh'ing into isn't know yet, you'll be asked to confirm the fingerprint of the target host. To do so, do the following:
# Find someone that has working SSH to the host or find other means of access to the host that doesn't require SSH.
# On the target host, run the command 'ssh-keyscan <host> | ssh-keygen -lf -'. Replace '<host>' with the target's hostname.
# Verifiy if the signature matches with the one shown by the initial ssh attempt. Make sure to check/match for the same algorithm.

Example:

On the initial host:

root@screwdriver:~# ssh scorpion

The authenticity of host 'scorpion (<no hostip for proxy command>)' can't be established.

ED25519 key fingerprint is SHA256:sjf89wi3rnwlkefn(IA(S*HANFlhfalknfsdfsadjfh.

This key is not known by any other names.

Are you sure you want to continue connecting (yes/no/[fingerprint])?

On the target host:

root@scorpion:~# ssh-keyscan scorpion | ssh-keygen -lf -

\# scorpion:22 SSH-2.0-OpenSSH_9.2p1 Debian-2+deb12u3

256 SHA256:lklsjdfsd8fd8*SDHANNAoaiodfnslakkfndsldkfn scorpion (ECDSA)

3072 SHA256:LKSdfjsi878sijn3lAUHUI&*GNSLFSadhofsnlka scorpion (RSA)

256 SHA256:sjf89wi3rnwlkefn(IA(S*HANFlhfalknfsdfsadjfh scorpion (ED25519)

Here, the algorithm is defined by the inital host as 'ED25519', and on the target host you match the fingerprint to the fingerprint on the line with the same algorithm name in braces, so '(ED25519)' in this case.

The fingerprints match, so you can accept the fingerprint on the initial host. If they do not match, do NOT accept, as your connection could be intercepted.

Ssh-fingerprints

2024-08-12T15:33:41Z

Dortund:

If the host you're ssh'ing into isn't know yet, you'll be asked to confirm the fingerprint of the target host. To do so, do the following:
# Find someone that has working SSH to the host or find other means of access to the host that doesn't require SSH.
# On the target host, run the command 'ssh-keyscan <host> | ssh-keygen -lf -'. Replace '<host>' with the target's hostname.
# Verifiy if the signature matches with the one shown by the initial ssh attempt. Make sure to check/match for the same algorithm.

Example:

On the initial host:
root@screwdriver:~# ssh scorpion
The authenticity of host 'scorpion (<no hostip for proxy command>)' can't be established.
ED25519 key fingerprint is SHA256:sjf89wi3rnwlkefn(IA(S*HANFlhfalknfsdfsadjfh.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

On the target host:
root@scorpion:~# ssh-keyscan scorpion | ssh-keygen -lf -
\# scorpion:22 SSH-2.0-OpenSSH_9.2p1 Debian-2+deb12u3
256 SHA256:lklsjdfsd8fd8*SDHANNAoaiodfnslakkfndsldkfn scorpion (ECDSA)
3072 SHA256:LKSdfjsi878sijn3lAUHUI&*GNSLFSadhofsnlka scorpion (RSA)
256 SHA256:sjf89wi3rnwlkefn(IA(S*HANFlhfalknfsdfsadjfh scorpion (ED25519)

Here, the algorithm is defined by the inital host as 'ED25519', and on the target host you match the fingerprint to the fingerprint on the line with the same algorithm name in braces, so '(ED25519)' in this case.

The fingerprints match, so you can accept the fingerprint on the initial host. If they do not match, do NOT accept, as your connection could be intercepted.

Ssh-fingerprints

2024-08-12T15:33:19Z

Dortund: Created page with "If the host you're ssh'ing into isn't know yet, you'll be asked to confirm the fingerprint of the target host. To do so, do the following: # Find someone that has working SSH to the host or find other means of access to the host that doesn't require SSH. # On the target host, run the command 'ssh-keyscan <host> | ssh-keygen -lf -'. Replace '<host>' with the target's hostname. # Verifiy if the signature matches with the one shown by the initial ssh attempt. Make sure to c..."

If the host you're ssh'ing into isn't know yet, you'll be asked to confirm the fingerprint of the target host. To do so, do the following:
# Find someone that has working SSH to the host or find other means of access to the host that doesn't require SSH.
# On the target host, run the command 'ssh-keyscan <host> | ssh-keygen -lf -'. Replace '<host>' with the target's hostname.
# Verifiy if the signature matches with the one shown by the initial ssh attempt. Make sure to check/match for the same algorithm.

Example:
On the initial host:
root@screwdriver:~# ssh scorpion
The authenticity of host 'scorpion (<no hostip for proxy command>)' can't be established.
ED25519 key fingerprint is SHA256:sjf89wi3rnwlkefn(IA(S*HANFlhfalknfsdfsadjfh.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

On the target host:
root@scorpion:~# ssh-keyscan scorpion | ssh-keygen -lf -
# scorpion:22 SSH-2.0-OpenSSH_9.2p1 Debian-2+deb12u3
256 SHA256:lklsjdfsd8fd8*SDHANNAoaiodfnslakkfndsldkfn scorpion (ECDSA)
3072 SHA256:LKSdfjsi878sijn3lAUHUI&*GNSLFSadhofsnlka scorpion (RSA)
256 SHA256:sjf89wi3rnwlkefn(IA(S*HANFlhfalknfsdfsadjfh scorpion (ED25519)

Here, the algorithm is defined by the inital host as 'ED25519', and on the target host you match the fingerprint to the fingerprint on the line with the same algorithm name in braces, so '(ED25519)' in this case.

The fingerprints match, so you can accept the fingerprint on the initial host. If they do not match, do NOT accept, as your connection could be intercepted.

Internal

2024-08-12T15:25:38Z

Dortund: /* SRE */

== Finance ==

=== Exact ===

* [[booking bonus|Booking bonus]]
* [[booking wages|Booking wages]]
* [[booking quarterly hosting invoice|Booking quarterly hosting invoice]]
* [[new receipt|Enter a new receipt]]
* [[reconciliation|Reconciliation of transaction]]
* [[invoicing|Send an invoice]]
* [[payment reminders|Send payment reminder]]
* [[invoice approval|Process for approving invoices (/filed receipts)]]

=== Bunq ===

* [[top up account|Top up expense account]]

== Work Process ==

* [[Definition of done|Definition of Done]]
* [[Incident Handling|Incident Handling]]
* [[SRE Maintenance|SRE Maintenance]]

== Internal Process ==
* [[timetracking|Timetracking process]]
* [[Starting work for a new client]]
* [[12 percent|12% time]]
* [[Annual leave|Annual leave]]
* [[Bonus allocation|Bonus allocation]]
* [[Calamity leave|Calamity leave]]
* [[Overtime|Overtime]]
* [[Retrospectives|Retrospectives]]
* [[Sick leave|Sick leave]]
* [[Training and self-study|Training and Self-Study]]
* [[Daily|Daily]]

== Projects ==

* Era Inventory [[project_era_inventory_api|API Description]]

== SRE ==

''To be further populated with guide from drive''
* [[create gitlab runner host|Create a GitLab runner host]]
* [[vm setup|Create a (Debian) VM]]
* [[border update|Process for updating a border]]
* [[border reboot|Reboot border without downtime]]
* [[WS Proxmox node reboot|Reboot WS Proxmox node without downtime]]
* [[Resize VM Disk]]
* [[SRE tools]]
* [[Enroll Mac in Kerberos]]
* [[Creating a VM on Hetzner]]
* [[Rebooting VM]]
* [[Rebooting Offsite]]
* [[ssh-fingerprints|Verifying SSH fingerprints]]

== Other ==

* [[stack|Greenfield stack]]
* [[standard tools|Standard Tools]]
* [[list of unfurl debuggers|List of unfurl debuggers]]
* [[Recommended suppliers]]

WS Proxmox node reboot

2024-08-12T13:55:50Z

Dortund:

== Tips & Notes ==
* If you're expecting to reboot every node in the cluster, do the node with the containers last, to limit the amount of downtime and reboots for them
* Updating a node: `apt update` and `apt full-upgrade`
* Make sure all VMs are actually migratable before adding to a HA group
* If there are containers on the device you are looking to reboot- you are going to need to also create a maintenance mode to cover them (for example teamspeak or awstats)
* Containers will inherit the OS of their host, so you will also need to handle triggers related to their OS updating, where appropriate
== Pre-Work ==
* If a VM or container is going to incur downtime, you must let the affected parties know in advance. Ideally they should be informed the previous day.

== Pre-flight checks ==
* Check all Ceph pools are running on at least 3/2 replication
* Check that all running VM's on the node you want to reboot are in HA (if not, add them or migrate them away manually)
* Check that Ceph is healthy -> No remapped PG's, or degraded data redundancy
* You have communicated that downtime is expected to the users who will be affected (Ideally one day in advance)

== Update Process ==
* Update the node: `apt update` and `apt full-upgrade`
* Check the packages that are removed/updated/installed correctly and they are the sane (to make sense)

== Reboot process ==
* Complete the pre-flight checks
* If you want to reboot for a kernel update, make sure the kernel is updated by following the Update Process written above
* Start maintenance mode for the Proxmox node and any containers running on the node
* Start maintenance mode for Ceph, specify that we only want to surpress the trigger for health state being in warning by setting tag `ceph_health` equals `warning`
* Let affected parties know that the mainenance period you told them about in the preflight checks is about to take place.
[[File:Ceph-maintenance.png|thumb]]
* Set noout flag on host: `ceph osd set-group noout <node>`

# gain ssh access to host
# Log in through IPA
# Run the command
* '''Reboot''' node through web GUI
* Wait for node to come back up
* Wait for OSD's to be back online
* Remove noout flag on host: `ceph osd unset-group noout <node>` ,to do this:
* If a kernel update was done, manually execute the `Operating system` item manually to detect the update. Manually executing the two items that indicate a reboot is also usefull if they were firing, to stop them/check no further reboots are needed.
* Ackowledge & close triggers
* Remove maintenance modes

== Aftercare ==
* Ensure that Kaboom API is running on Screwdriver or Paloma. This is to get the best performance for the VM.

Timetracking

2024-08-07T16:39:24Z

Dortund:

* If an non-critical incident breaks SLO, or a critical incident takes more than one week to be fully completed (such as by having spin-off tasks)
* Misc -> sales is only for making sales without a lead. So if it's to sell/agree on price for a feature for a client, that time should be put on the milestone for that client

Timetracking

2024-08-07T16:38:32Z

Dortund: Created page with "* If an non-critical incident breaks SLO, or a critical incident takes more than one week to be fully completed (such as by having spin-off tasks)"

* If an non-critical incident breaks SLO, or a critical incident takes more than one week to be fully completed (such as by having spin-off tasks)

Internal

2024-08-07T16:37:26Z

Dortund: /* Internal Process */

== Finance ==

=== Exact ===

* [[booking bonus|Booking bonus]]
* [[booking wages|Booking wages]]
* [[booking quarterly hosting invoice|Booking quarterly hosting invoice]]
* [[new receipt|Enter a new receipt]]
* [[reconciliation|Reconciliation of transaction]]
* [[invoicing|Send an invoice]]
* [[payment reminders|Send payment reminder]]
* [[invoice approval|Process for approving invoices (/filed receipts)]]

=== Bunq ===

* [[top up account|Top up expense account]]

== Work Process ==

* [[Definition of done|Definition of Done]]
* [[Incident Handling|Incident Handling]]
* [[SRE Maintenance|SRE Maintenance]]

== Internal Process ==
* [[timetracking|Timetracking process]]
* [[Starting work for a new client]]
* [[12 percent|12% time]]
* [[Annual leave|Annual leave]]
* [[Bonus allocation|Bonus allocation]]
* [[Calamity leave|Calamity leave]]
* [[Overtime|Overtime]]
* [[Retrospectives|Retrospectives]]
* [[Sick leave|Sick leave]]
* [[Training and self-study|Training and Self-Study]]
* [[Daily|Daily]]

== Projects ==

* Era Inventory [[project_era_inventory_api|API Description]]

== SRE ==

''To be further populated with guide from drive''
* [[create gitlab runner host|Create a GitLab runner host]]
* [[vm setup|Create a (Debian) VM]]
* [[border update|Process for updating a border]]
* [[border reboot|Reboot border without downtime]]
* [[WS Proxmox node reboot|Reboot WS Proxmox node without downtime]]
* [[Resize VM Disk]]
* [[SRE tools]]
* [[Enroll Mac in Kerberos]]
* [[Creating a VM on Hetzner]]
* [[Rebooting VM]]

== Other ==

* [[stack|Greenfield stack]]
* [[standard tools|Standard Tools]]
* [[list of unfurl debuggers|List of unfurl debuggers]]
* [[Recommended suppliers]]

Booking bonus

2024-08-07T14:19:11Z

Dortund:

== Calculating bonus ==

# Obtain the bonus calculation template from 'Money' channel
# Use steps from help tab to fill in the sheet
# Save file as '<year>-Q<quarter>-bonus.xlsx' and export as pdf
# Post pdf version of file in 'Money' channel

=== Requirements ===

* Bonus PDF needs to be ready by the 5th, in order for it to be approved and sent to accountants on time.
* Bonus needs to filed in Exact by the quarterly meeting, if it is approved.
* All receipts needs to filed and reconciled in order for the bonus to be approved.

== Create bonus booking on exact ==

# Exact
# Financieel
# Boeken en grootboekrekeningen
# Boekingen
# Aanmaken
# Click '91 - Bonus verdeling'
# First line item
## Set 'Datum' to last day of the quarter you're booking the bonus for (e.g. December 31st when booking Q4 bonus)
## Set 'Grootboekrekening' to '4010 - Bijzondere beloning'
## Set 'Omschrijving' to 'Bonuskosten <year> Q<quarter>'
## Set 'Debet' to total bonus to be paid out as calculated in sheet (under 'Bonus costs')
# Line item for every employee that receives a bonus (as calculated in bonus sheet)
## Set 'Datum' to same value as first line
## Set 'Grootboekrekening' to '1790 - Te betalen bonussen'
## Set 'Omschrijving to 'Bonuskosten <year> Q<quarter> <employee name>'
## Set 'Credit' to amount of bonus for that employee (as calculated in bonus sheet)
# Line item for every owner that receives a bonus (as calculated in bonus sheet)
## Set 'Datum' to same value as first line
## Set 'Grootboekrekening' to '4010 - Bijzondere beloning'
## Set 'Omschrijving to 'Bonuskosten <year> Q<quarter> <owner name>'
## Set 'Credit' to amount of bonus for that owner (as calculated in bonus sheet)
# If at this point there is a small difference between Debet and Credit (and all entered numbers are correct), you can create a line with Grootboekrekening '9200 - Rekenverschillen' to make up for the difference

== Attach bonus calc sheet to booking in Exact ==

# Exact
# Documenten
# Nieuw document
# Subject: 'Bonus <year>-Q<quarter>'
# Categorie: 'Crediteuren'
# Date: Today
# Delen: Huidige administratie
# Type: Bijlage
# Boeking: The bonus booking for that quarter
# Attach the pdf version of the bonus calc sheet

Booking wages

2024-08-05T14:50:08Z

Dortund:

== Wage slips ==

# Exact
# Financieel > Boekingen en grootboekrekeningen > Boekingen > Aanmaken (English: Financial -> Entries & G/L Accounts -> Entries -> Create)
# Inkoop > '''80 - Salarisstroken'''
# Add file (wage slip)
# Set `Supplier` to the person this wage slip meant for
# Beschijving: Salaris periode {YEAR}-{MONTH}-M / {YEAR}-{MONTH}-M {NAME}
# Ensure `Payment condition` is set to `M - Einde volgende maand`
# Ensure `Invoice date` is set to the beginning of the month
# Totaalbedrag: Set to '''Totaal netto''' from the wage slip
# Line items:
## From the wage slip's '''Bruto > Salaris''' add the value of it as '''Bruto loon (4000)''', with description 'Salaris periode {YEAR}-{MONTH}-M / {YEAR}-{MONTH}-M {NAME}'
## From the wage slip's '''Bruto > Bonus (BT)''' if present, add the value of it as '''Te betalen bonussen (1790)'''
## From the wage slip's '''Loonheffing''' add the value of it as a negative amount as '''af te dragen loonheffing (1700)''', with description 'Salaris LH periode {YEAR}-{MONTH}-M / {YEAR}-{MONTH}-M {NAME}'
## From the wage slip's '''Netto > Onkostenvergoeding''' if present, add the value of it as '''Kosten nettovergoedingen'''

== Wage taxes ==
# Exact
# Financieel > Boekingen en grootboekrekeningen > Boekingen > Aanmaken
# Inkoop > '''80 - Salarisstroken'''
# Add file (LH/'Loonaangifte_Bedrijf_Overzicht_Delft_Solutions_BV_*.pdf)
# Set `Supplier` to `Belastingdienst`
# Beschrijving: Enter the value for ''LHnummer en volgnummer'' from the document
# Ensure `Payment Condition` is set to `D - Deze maand`
# Ensure `Invoice date` is set to the beginning of the month, if the 'send' date on the document is not of the current month. Otherwise, just set the 'send' date
# Set `Total amount` to the value of `Totaal Generaal` from the document
# Line items:
## From the document's '''Loonbelasting / premie volksverzekering''' add the section's total value as '''Af te dragen loonheffing (1700)''' with description `Loonbelasting / premie volksverzekering {YEAR}-{MONTH}`
## From the document's '''Premies''' add the section's total value as '''Kosten sociale premies werkgever (4041)''' with description `Premies {YEAR}-{MONTH}`

== Pension ==

# Exact
# Financieel > Boekingen en grootboekrekeningen > Boekingen > Aanmaken
# Inkoop > '''80 - Salarisstroken'''
# Add file (JP/'Journaalposten_Delft_Solutions_BV_*.pdf)
# Set `Supplier` to `Bright Pensions N.V.`
# Beschrijving: Pensioen {YEAR}-{MONTH}-M
# Ensure `Payment condition` is set to `IN - Incasso`
# Ensure `Invoice date` is set to the the '16th' of the month of the period over which the document documents the pension payments. (Look at 'Periodes' for this)
# Totaalbedrag: Set to the value of '''Pensioenafdracht WG en WN''' on the document
# Line items:
## For each person who received pension payment: '''Pensioenen (4011)''' with description `Pensioen {YEAR}-{MONTH}-M {NAME}` and with the correct value (At the moment, 1/3 of the total amount per person).

== Reconciliation (after payment) ==
# Financieel > Boekingen en grootboekrekeningen > Overzichten > Kaarten (In English: Financial > Entries & G/L Accounts > Reports > Transactions)
# Search for '''Af te dragen loonheffing (1700)'''. Ensure the relevant `Financial year` is selected.
# First, only mark (not actually match) the wage slips together with the IRS slip for wage taxes. The difference at the bottom (e.g. 0.16 EUR) needs to be added to the wage tax document.
## For line item '''Af te dragen loonheffing (1700)''' add the difference to the current value (0.16 EUR in this example)
## Create line item '''Rekenverschillen (9200)''' with description {ENTRY_DESCRIPTION} {YEAR}-{MONTH} and the value in negative (-0.16 EUR in this example)
## Mark the wage slips together with the IRS slip for wage taxes again. The difference should now be 0.
# Select `Match` at the top of the screen to match the entries.

== Reconciliation of the payment itself ==
# Go to Financial > Banking & Cash > Statements > To be completed and search for `to be completed` statements.
# Ensure the G/L account is set to `1671 - Te betalen lonen`, and the account is set to `1 - Belastingdienst`.
# Select `Match` and select the matching entry (Previously created in the `Wage Taxes` section).

== Reconciliation of the pension payments ==
# Go to Financial > Banking & Cash > Statements > To be completed and search for `to be completed` statements.
# Ensure the G/L is set to `1671 - Te betalen lonen`, and the account is set to `47 - Bring Pensions N.V.` for the three pension payments.
# Click 'Match' on any of the pension payments
# In the modal, check the checkbox for the other two pension payments, and the correct pension document entry (The one created earlier in the `Pension` section). Finally, click `Enter`.

== Preparing wage payments ==
# Create a payment scheduled on the correct date (15th of the month) for 12:00 (Midday), for each wage slip added, with the description `Salaris periode {YEAR}-{MONTH}-M {NAME}`

Booking wages

2024-08-05T14:16:53Z

Dortund:

== Wage slips ==

# Exact
# Financieel > Boekingen en grootboekrekeningen > Boekingen > Aanmaken (English: Financial -> Entries & G/L Accounts -> Entries -> Create)
# Inkoop > '''80 - Salarisstroken'''
# Add file (wage slip)
# Set `Supplier` to the person this wage slip meant for
# Beschijving: Salaris periode {YEAR}-{MONTH}-M / {YEAR}-{MONTH}-M {NAME}
# Ensure `Payment condition` is set to `M - Einde volgende maand`
# Ensure `Invoice date` is set to the beginning of the month
# Totaalbedrag: Set to '''Totaal netto''' from the wage slip
# Line items:
## From the wage slip's '''Bruto > Salaris''' add the value of it as '''Bruto loon (4000)''',
## From the wage slip's '''Bruto > Bonus (BT)''' if present, add the value of it as '''Te betalen bonussen (1790)'''
## From the wage slip's '''Loonheffing''' add the value of it as a negative amount as '''af te dragen loonheffing (1700)'''
## From the wage slip's '''Netto > Onkostenvergoeding''' if present, add the value of it as '''Kosten nettovergoedingen'''

== Wage taxes ==
# Exact
# Financieel > Boekingen en grootboekrekeningen > Boekingen > Aanmaken
# Inkoop > '''80 - Salarisstroken'''
# Add file (LH/'Loonaangifte_Bedrijf_Overzicht_Delft_Solutions_BV_*.pdf)
# Set `Supplier` to `Belastingdienst`
# Beschrijving: Enter the value for ''LHnummer en volgnummer'' from the document
# Ensure `Payment Condition` is set to `D - Deze maand`
# Ensure `Invoice date` is set to the beginning of the month, if the 'send' date on the document is not of the current month. Otherwise, just set the 'send' date
# Set `Total amount` to the value of `Totaal Generaal` from the document
# Line items:
## From the document's '''Loonbelasting / premie volksverzekering''' add the section's total value as '''Af te dragen loonheffing (1700)''' with description `Loonbelasting / premie volksverzekering {YEAR}-{MONTH}`
## From the document's '''Premies''' add the section's total value as '''Kosten sociale premies werkgever (4041)''' with description `Premies {YEAR}-{MONTH}`

== Pension ==

# Exact
# Financieel > Boekingen en grootboekrekeningen > Boekingen > Aanmaken
# Inkoop > '''80 - Salarisstroken'''
# Add file (JP/'Journaalposten_Delft_Solutions_BV_*.pdf)
# Set `Supplier` to `Bright Pensions N.V.`
# Beschrijving: Pensioen {YEAR}-{MONTH}-M
# Ensure `Payment condition` is set to `IN - Incasso`
# Ensure `Invoice date` is set to the the '16th' of the month of the period over which the document documents the pension payments. (Look at 'Periodes' for this)
# Totaalbedrag: Set to the value of '''Pensioenafdracht WG en WN''' on the document
# Line items:
## For each person who received pension payment: '''Pensioenen (4011)''' with description `Pensioen {YEAR}-{MONTH}-M {NAME}` and with the correct value (At the moment, 1/3 of the total amount per person).

== Reconciliation (after payment) ==
# Financieel > Boekingen en grootboekrekeningen > Overzichten > Kaarten (In English: Financial > Entries & G/L Accounts > Reports > Transactions)
# Search for '''Af te dragen loonheffing (1700)'''. Ensure the relevant `Financial year` is selected.
# First, only mark (not actually match) the wage slips together with the IRS slip for wage taxes. The difference at the bottom (e.g. 0.16 EUR) needs to be added to the wage tax document.
## For line item '''Af te dragen loonheffing (1700)''' add the difference to the current value (0.16 EUR in this example)
## Create line item '''Rekenverschillen (9200)''' with description {ENTRY_DESCRIPTION} {YEAR}-{MONTH} and the value in negative (-0.16 EUR in this example)
## Mark the wage slips together with the IRS slip for wage taxes again. The difference should now be 0.
# Select `Match` at the top of the screen to match the entries.

== Reconciliation of the payment itself ==
# Go to Financial > Banking & Cash > Statements > To be completed and search for `to be completed` statements.
# Ensure the G/L account is set to `1671 - Te betalen lonen`, and the account is set to `1 - Belastingdienst`.
# Select `Match` and select the matching entry (Previously created in the `Wage Taxes` section).

== Reconciliation of the pension payments ==
# Go to Financial > Banking & Cash > Statements > To be completed and search for `to be completed` statements.
# Ensure the G/L is set to `1671 - Te betalen lonen`, and the account is set to `47 - Bring Pensions N.V.` for the three pension payments.
# Click 'Match' on any of the pension payments
# In the modal, check the checkbox for the other two pension payments, and the correct pension document entry (The one created earlier in the `Pension` section). Finally, click `Enter`.

== Preparing wage payments ==
# Create a payment scheduled on the correct date (15th of the month) for 12:00 (Midday), for each wage slip added, with the description `Salaris periode {YEAR}-{MONTH}-M {NAME}`

Border reboot

2024-08-05T12:53:13Z

Dortund:

Note: Throughout this guide <ipv4> and <ipv6> are to be replaced by the correct IP's. If you don't know, you can press the 'tab' key (twice) on your keyboard after typing 'neighbors' to get shown the options.

== Pre-flight checks ==
These checks are to be done on the '''OTHER''' border (So the border that will stay online), to ensure that when the border that's being rebooted is down the cluster won't lose network connectivity. The commands are to be invoked in `vtysh`.
* Confirm our IPv4 block is announced over BGP with `show ip bgp neighbors <ipv4> advertised-routes`
* Confirm our IPv6 block is announced over BGP with `show bgp neighbors <ipv6> advertised-routes`
* Confirm that the border receives the ROUTED IPv4 routes from the router with `show ip route`
* Confirm that the border received the ROUTED & LAN IPv6 routes from the router with `show ipv6 route`
* Set a maintenance period for the host on Zabbix.
* Post in the Zulip in the relevant topic (incident's topic / 'SRE - General' stream) that the border is going to be rebooted.

== Disabling routing through a border ==
* First, perform the pre-flight checks on the '''OTHER''' border.
* Second, set a maintenance period on Zabbix for the border that's being rebooted.

Third, on a border in `vtysh`, update the running configuration by invoking the following:

* config
* router bgp
* neighbor <ipv4> shutdown
* neighbor <ipv6> shutdown
* exit
* router ospf
* no default-information originate
* exit
* router ospf6
* no default-information originate
* exit
* exit
* exit

== Reboot the border ==

* After performing the pre-flight checks and disabling the routing, you can choose to wait until traffic has decreased (e.g. using `bmon` to check bandwidth used on interfaces)
* Execute `reboot` command
* When the border is back online, execute relavant items (system uptime, operating system, reboot required) to ensure these will not activate a trigger after disabling maintenance mode
* If you do not expect any Zabbix alert related to the reboot to be fired, delete the maintenance period

== Troubleshooting ==

Undoing the shutdown of the neighbors can be done by invoking `no neighbor <ipv4>/<ipv6> shutdown` in the `router bgp` part of the configuration.

And the `no default-information originate` can be undone by invoking `default-information originate` in the corect ospf part of the configuration (ospf or ospf6, depending on which one you wish to re-enable).

A reload/restart of the service will also reset to normal configuration.

Border reboot

2024-08-05T09:24:51Z

Dortund:

Note: Throughout this guide <ipv4> and <ipv6> are to be replaced by the correct IP's. If you don't know, you can press the 'tab' key (twice) on your keyboard after typing 'neighbors' to get shown the options.

== Pre-flight checks ==
These checks are to be done on the '''OTHER''' border (So the border that will stay online), to ensure that when the border that's being rebooted is down the cluster won't lose network connectivity. The commands are to be invoked in `vtysh`.
* Confirm our IPv4 block is announced over BGP with `show ip bgp neighbors <ipv4> advertised-routes`
* Confirm our IPv6 block is announced over BGP with `show bgp neighbors <ipv6> advertised-routes`
* Confirm that the border receives the ROUTED IPv4 routes from the router with `show ip route`
* Confirm that the border received the ROUTED & LAN IPv6 routes from the router with `show ipv6 route`
* Set a maintenance period for the host on Zabbix.
* Post in the Zulip in the relevant topic (incident's topic / 'SRE - General' stream) that the border is going to be rebooted.

== Disabling routing through a border ==
First, perform the pre-flight checks on the '''OTHER''' border

On a border in `vtysh`, update the running configuration by invoking the following:

* config
* router bgp
* neighbor <ipv4> shutdown
* neighbor <ipv6> shutdown
* exit
* router ospf
* no default-information originate
* exit
* router ospf6
* no default-information originate
* exit
* exit
* exit

== Reboot the border ==

* After performing the pre-flight checks and disabling the routing, you can choose to wait until traffic has decreased (e.g. using `bmon` to check bandwidth used on interfaces)
* Execute `reboot` command
* When the border is back online, execute relavant items (system uptime, operating system, reboot required) to ensure these will not activate a trigger after disabling maintenance mode
* If you do not expect any Zabbix alert related to the reboot to be fired, delete the maintenance period

== Troubleshooting ==

Undoing the shutdown of the neighbors can be done by invoking `no neighbor <ipv4>/<ipv6> shutdown` in the `router bgp` part of the configuration.

And the `no default-information originate` can be undone by invoking `default-information originate` in the corect ospf part of the configuration (ospf or ospf6, depending on which one you wish to re-enable).

A reload/restart of the service will also reset to normal configuration.

Border reboot

2024-08-05T09:23:49Z

Dortund:

Note: Throughout this guide <ipv4> and <ipv6> are to be replaced by the correct IP's. If you don't know, you can press the 'tab' key (twice) on your keyboard after typing 'neighbors' to get shown the options.

== Preflight checks ==
These checks are to be done on the '''other''' border (So the border that will stay online), to ensure that when the border that's being rebooted is down the cluster won't lose network connectivity. The commands are to be invoked in `vtysh`.
* Confirm our IPv4 block is announced over BGP with `show ip bgp neighbors <ipv4> advertised-routes`
* Confirm our IPv6 block is announced over BGP with `show bgp neighbors <ipv6> advertised-routes`
* Confirm that the border receives the ROUTED IPv4 routes from the router with `show ip route`
* Confirm that the border received the ROUTED & LAN IPv6 routes from the router with `show ipv6 route`
* Set a maintenance period for the host on Zabbix.
* Post in the Zulip in the relevant topic (incident's topic / 'SRE - General' stream) that the border is going to be rebooted.

== Disabling routing through a border ==
On a border in `vtysh`, update the running configuration by invoking the following:

* config
* router bgp
* neighbor <ipv4> shutdown
* neighbor <ipv6> shutdown
* exit
* router ospf
* no default-information originate
* exit
* router ospf6
* no default-information originate
* exit
* exit
* exit

== Reboot the border ==

* After performing the pre-flight checks and disabling the routing, you can choose to wait until traffic has decreased (e.g. using `bmon` to check bandwidth used on interfaces)
* Execute `reboot` command
* When the border is back online, execute relavant items (system uptime, operating system, reboot required) to ensure these will not activate a trigger after disabling maintenance mode
* If you do not expect any Zabbix alert related to the reboot to be fired, delete the maintenance period

== Troubleshooting ==

Undoing the shutdown of the neighbors can be done by invoking `no neighbor <ipv4>/<ipv6> shutdown` in the `router bgp` part of the configuration.

And the `no default-information originate` can be undone by invoking `default-information originate` in the corect ospf part of the configuration (ospf or ospf6, depending on which one you wish to re-enable).

A reload/restart of the service will also reset to normal configuration.

Border reboot

2024-08-05T09:22:56Z

Dortund:

Note: Throughout this guide <ipv4> and <ipv6> are to be replaced by the correct IP's. If you don't know, you can press the 'tab' key (twice) on your keyboard after typing 'neighbors' to get shown the options.

== Preflight checks ==
These checks are to be done on the '''other''' border (So the border that will stay online). The commands are to be invoked in `vtysh`.
* Confirm our IPv4 block is announced over BGP with `show ip bgp neighbors <ipv4> advertised-routes`
* Confirm our IPv6 block is announced over BGP with `show bgp neighbors <ipv6> advertised-routes`
* Confirm that the border receives the ROUTED IPv4 routes from the router with `show ip route`
* Confirm that the border received the ROUTED & LAN IPv6 routes from the router with `show ipv6 route`
* Set a maintenance period for the host on Zabbix.
* Post in the Zulip in the relevant topic (incident's topic / 'SRE - General' stream) that the border is going to be rebooted.

== Disabling routing through a border ==
On a border in `vtysh`, update the running configuration by invoking the following:

* config
* router bgp
* neighbor <ipv4> shutdown
* neighbor <ipv6> shutdown
* exit
* router ospf
* no default-information originate
* exit
* router ospf6
* no default-information originate
* exit
* exit
* exit

== Reboot the border ==

* After performing the pre-flight checks and disabling the routing, you can choose to wait until traffic has decreased (e.g. using `bmon` to check bandwidth used on interfaces)
* Execute `reboot` command
* When the border is back online, execute relavant items (system uptime, operating system, reboot required) to ensure these will not activate a trigger after disabling maintenance mode
* If you do not expect any Zabbix alert related to the reboot to be fired, delete the maintenance period

== Troubleshooting ==

Undoing the shutdown of the neighbors can be done by invoking `no neighbor <ipv4>/<ipv6> shutdown` in the `router bgp` part of the configuration.

And the `no default-information originate` can be undone by invoking `default-information originate` in the corect ospf part of the configuration (ospf or ospf6, depending on which one you wish to re-enable).

A reload/restart of the service will also reset to normal configuration.

WS Proxmox node reboot

2024-07-29T14:40:42Z

Dortund:

== Tips & Notes ==
* If you're expecting to reboot every node in the cluster, do the node with the containers last, to limit the amount of downtime and reboots for them
* Updating a node: `apt update` and `apt full-upgrade`
* Make sure all VMs are actually migratable before adding to a HA group
* If there are containers on the device you are looking to reboot- you are going to need to also create a maintenance mode to cover them (for example teamspeak or awstats)
* Containers will inherit the OS of their host, so you will also need to handle triggers related to their OS updating, where appropriate
== Pre-Work ==
* If a VM or container is going to incur downtime, you must let the affected parties know in advance. Ideally they should be informed the previous day.

== Pre flight checks ==
* Check all Ceph pools are running on at least 3/2 replication
* Check that all running VM's on the node you want to reboot are in HA (if not, add them or migrate them away manually)
* Check that Ceph is healthy -> No remapped PG's, or degraded data redundancy
* You have communicated that downtime is expected to the users who will be affected (Ideally one day in advance)

== Reboot process ==
* Start maintenance mode for the Proxmox node and any containers running on the node
* Start maintenance mode for Ceph, specify that we only want to surpress the trigger for health state being in warning by setting tag `ceph_health` equals `warning`
* Let affected parties know that the mainenance period you told them about in the preflight checks is about to take place.
[[File:Ceph-maintenance.png|thumb]]
* Set noout flag on host: `ceph osd set-group noout <node>`
* '''Reboot''' node through web GUI
* Wait for node to come back up
* Wait for OSD's to be back online
* Remove noout flag on host: `ceph osd unset-group noout <node>` ,to do this:

# gain ssh access to host
# Log in through IPA
# Run the command

* If a kernel update was done, manually execute the `Operating system` item manually to detect the update. Manually executing the two items that indicate a reboot is also usefull if they were firing, to stop them/check no further reboots are needed.
* Ackowledge & close triggers
* Remove maintenance modes

== Aftercare ==
* Ensure that Kaboom API is running on Screwdriver or Paloma. This is to get the best performance for the VM.

Border reboot

2024-07-29T12:24:14Z

Dortund:

Note: Throughout this guide <ipv4> and <ipv6> are to be replaced by the correct IP's. If you don't know, you can press the 'tab' key (twice) on your keyboard after typing 'neighbors' to get shown the options.

== Preflight checks ==
These checks are to be done on the other border (So the border that will stay online). The commands are to be invoked in `vtysh`.
* Confirm our IPv4 block is announced over BGP with `show ip bgp neighbors <ipv4> advertised-routes`
* Confirm our IPv6 block is announced over BGP with `show bgp neighbors <ipv6> advertised-routes`
* Confirm that the border receives the ROUTED IPv4 routes from the router with `show ip route`
* Confirm that the border received the ROUTED & LAN IPv6 routes from the router with `show ipv6 route`
* Set a maintenance period for the host on Zabbix.
* Post in the Zulip in the relevant topic (incident's topic / 'SRE - General' stream) that the border is going to be rebooted.

== Disabling routing through a border ==
On a border in `vtysh`, update the running configuration by invoking the following:

* config
* router bgp
* neighbor <ipv4> shutdown
* neighbor <ipv6> shutdown
* exit
* router ospf
* no default-information originate
* exit
* router ospf6
* no default-information originate
* exit
* exit
* exit

== Reboot the border ==

* After performing the pre-flight checks and disabling the routing, you can choose to wait until traffic has decreased (e.g. using `bmon` to check bandwidth used on interfaces)
* Execute `reboot` command
* When the border is back online, execute relavant items (system uptime, operating system, reboot required) to ensure these will not activate a trigger after disabling maintenance mode
* If you do not expect any Zabbix alert related to the reboot to be fired, delete the maintenance period

== Troubleshooting ==

Undoing the shutdown of the neighbors can be done by invoking `no neighbor <ipv4>/<ipv6> shutdown` in the `router bgp` part of the configuration.

And the `no default-information originate` can be undone by invoking `default-information originate` in the corect ospf part of the configuration (ospf or ospf6, depending on which one you wish to re-enable).

A reload/restart of the service will also reset to normal configuration.

Border reboot

2024-07-29T12:23:55Z

Dortund:

Note: Throughout this guide <ipv4> and <ipv6> are to be replaced by the correct IP's. If you don't know, you can press the 'tab' key (twice) on your keyboard after typing 'neighbors' to get shown the possibilities.

== Preflight checks ==
These checks are to be done on the other border (So the border that will stay online). The commands are to be invoked in `vtysh`.
* Confirm our IPv4 block is announced over BGP with `show ip bgp neighbors <ipv4> advertised-routes`
* Confirm our IPv6 block is announced over BGP with `show bgp neighbors <ipv6> advertised-routes`
* Confirm that the border receives the ROUTED IPv4 routes from the router with `show ip route`
* Confirm that the border received the ROUTED & LAN IPv6 routes from the router with `show ipv6 route`
* Set a maintenance period for the host on Zabbix.
* Post in the Zulip in the relevant topic (incident's topic / 'SRE - General' stream) that the border is going to be rebooted.

== Disabling routing through a border ==
On a border in `vtysh`, update the running configuration by invoking the following:

* config
* router bgp
* neighbor <ipv4> shutdown
* neighbor <ipv6> shutdown
* exit
* router ospf
* no default-information originate
* exit
* router ospf6
* no default-information originate
* exit
* exit
* exit

== Reboot the border ==

* After performing the pre-flight checks and disabling the routing, you can choose to wait until traffic has decreased (e.g. using `bmon` to check bandwidth used on interfaces)
* Execute `reboot` command
* When the border is back online, execute relavant items (system uptime, operating system, reboot required) to ensure these will not activate a trigger after disabling maintenance mode
* If you do not expect any Zabbix alert related to the reboot to be fired, delete the maintenance period

== Troubleshooting ==

Undoing the shutdown of the neighbors can be done by invoking `no neighbor <ipv4>/<ipv6> shutdown` in the `router bgp` part of the configuration.

And the `no default-information originate` can be undone by invoking `default-information originate` in the corect ospf part of the configuration (ospf or ospf6, depending on which one you wish to re-enable).

A reload/restart of the service will also reset to normal configuration.

Border reboot

2024-07-29T12:23:22Z

Dortund:

Note: Throughout this guide <ipv4> and <ipv6> are to be replaced by the correct IP's. If you don't know, you can press the 'tab' key on your keyboard after typing 'neighbors' to get shown the possibilities.

== Preflight checks ==
These checks are to be done on the other border (So the border that will stay online). The commands are to be invoked in `vtysh`.
* Confirm our IPv4 block is announced over BGP with `show ip bgp neighbors <ipv4> advertised-routes`
* Confirm our IPv6 block is announced over BGP with `show bgp neighbors <ipv6> advertised-routes`
* Confirm that the border receives the ROUTED IPv4 routes from the router with `show ip route`
* Confirm that the border received the ROUTED & LAN IPv6 routes from the router with `show ipv6 route`
* Set a maintenance period for the host on Zabbix.
* Post in the Zulip in the relevant topic (incident's topic / 'SRE - General' stream) that the border is going to be rebooted.

== Disabling routing through a border ==
On a border in `vtysh`, update the running configuration by invoking the following:

* config
* router bgp
* neighbor <ipv4> shutdown
* neighbor <ipv6> shutdown
* exit
* router ospf
* no default-information originate
* exit
* router ospf6
* no default-information originate
* exit
* exit
* exit

== Reboot the border ==

* After performing the pre-flight checks and disabling the routing, you can choose to wait until traffic has decreased (e.g. using `bmon` to check bandwidth used on interfaces)
* Execute `reboot` command
* When the border is back online, execute relavant items (system uptime, operating system, reboot required) to ensure these will not activate a trigger after disabling maintenance mode
* If you do not expect any Zabbix alert related to the reboot to be fired, delete the maintenance period

== Troubleshooting ==

Undoing the shutdown of the neighbors can be done by invoking `no neighbor <ipv4>/<ipv6> shutdown` in the `router bgp` part of the configuration.

And the `no default-information originate` can be undone by invoking `default-information originate` in the corect ospf part of the configuration (ospf or ospf6, depending on which one you wish to re-enable).

A reload/restart of the service will also reset to normal configuration.

New receipt

2024-07-18T12:08:31Z

Dortund:

# Log into Exact
# Go to “Purchase” > “Entries” > “Overview”
# Click “New”
# Click “60 - Inkoopboek”
# Add a picture of the receipt as an attachment
# Under “Supplier”, find the supplier and select the correct supplier
# Numbered list item
## If the supplier does not exist, you have to add a new supplier, but there is no guide for this
# Under “Invoice Data”
## Enter the description of what is on the receipt (e.g. enter “lunch stuff” for when you have a receipt for buying lunch stuff)
## Enter total amount on the receipt under “Total amount”
## Update “Invoice Date” (And probably also “Due date”) to match the date on the receipt
# Make sure the expenses are for the correct G/L Account, e.g. lunch/borrel stuff should be under 4012
# Make sure the VAT code is correct, as well as the VAT amount
## For receipts for food stuffs (lunch, drinks, diner, etc.), the VAT code needs to be `0` (`Geen BTW`), despite the fact that the receipt may state VAT
# Click “Save + new”
# Ask Vincent to reconcile the payment+receipt
# Done

Rebooting VM

2024-07-17T15:44:39Z

Dortund:

= Pre-flight checks =
'''These instructions are not for rebooting Proxmox nodes or borders in our cluster!'''
In the following informating 'host' will refer to either a VM, CT, or a physical server.

== Ensure the host is not actively being used ==
Someone might be working with the host. Rebooting it will interrupt their work, so make sure noone is working on the host.

Ensuring this can be done by checking in with everyone, or announcing a maintenance period in the 'Organisational' stream and ensuring everyone has read the announcement.

== Ensure rebooting the host does not interrupt an important process ==
Even though someone might not be actively working with a host, the host itself might be busy. Examples of this are: A client VM running a database migration, or a backup process is running.

Ensuring this can be done by also checking in with everyone, announcing a maintenance period ahead of time, or checking the host itself (or Zabbix for S3 backups)

== Ensure you have SSH access to the host ==
For personal dev VM's this should not be an issue, but for work VM's this will require you to request 'sla-temporary-access' to the host from the First Responder. It will take some time for the host to become aware of the change, so make sure to do this more then an hour ahead of time.

= Rebooting =
This is the process for rebooting the host itself:
# Perform the pre-flight checks listed above
# Create a maintenance period for the host itself
# SSH into the host
# Run `apt update`
# Verify that the packages to update are sane. Get packages with `apt list --upgradable`. See section 'Package sanity check' for further details
# Update packages with `apt full-upgrade`. Before accepting, check that no unexpected package changes are happening for installing/updating/removing.
# After the updates are completed, reboot the host with `reboot`
# Wait for the host to be rebooted. You can check Zabbix, ping, or trying to SSH into the host again to check.
# On Zabbix, go to 'Configuration' -> 'Hosts', and click on 'items' for the rebooted host.
# Search for 'reboot', select the checkbox for both items and click on 'Execute now'.
# Search for 'operating', select the checkbox for the item that has a trigger that uses it, and select 'Execugte now'.
# Go to 'Monitoring' -> 'Problems'. Check the checkbox for triggers that fired for this host. Expected are '<host> has been restarted' and 'Operating system description has changed'. Scroll to the bottom and click on 'Mass update'. In the modal, check the checkbox for 'close problem', 'acknowledge', and in the 'message' box write the reason the host was rebooted. For example 'host was rebooted due to kernel update'
# Remove the maintenance period from the host

== Package sanity check ==
Expected packages can be 'delftsolutions-*' for almost all hosts.
For Gitlab (runners), expected packages can also include the gitlab-ee package or gitlab-runner packages

Rebooting VM

2024-07-17T15:44:12Z

Dortund: Created page with "= Pre-flight checks = '''These instructions are not for rebooting Proxmox nodes or borders in our cluster!''' In the following informating 'host' will refer to either a VM, CT, or a physical server. == Ensure the host is not actively being used == Someone might be working with the host. Rebooting it will interrupt their work, so make sure noone is working on the host. Ensuring this can be done by checking in with everyone, or announcing a maintenance period in the 'Org..."

= Pre-flight checks =
'''These instructions are not for rebooting Proxmox nodes or borders in our cluster!'''
In the following informating 'host' will refer to either a VM, CT, or a physical server.

== Ensure the host is not actively being used ==
Someone might be working with the host. Rebooting it will interrupt their work, so make sure noone is working on the host.

Ensuring this can be done by checking in with everyone, or announcing a maintenance period in the 'Organisational' stream and ensuring everyone has read the announcement.

== Ensure rebooting the host does not interrupt an important process ==
Even though someone might not be actively working with a host, the host itself might be busy. Examples of this are: A client VM running a database migration, or a backup process is running.

Ensuring this can be done by also checking in with everyone, announcing a maintenance period ahead of time, or checking the host itself (or Zabbix for S3 backups)

== Ensure you have SSH access to the host ==
For personal dev VM's this should not be an issue, but for work VM's this will require you to request 'sla-temporary-access' to the host from the First Responder. It will take some time for the host to become aware of the change, so make sure to do this more then an hour ahead of time.

= Rebooting =
This is the process for rebooting the host itself:
# Perform the pre-flight checks listed above
# Create a maintenance period for the host itself
# SSH into the host
# Run `apt update`
# Verify that the packages to update are sane. Get packages with `apt list --upgradable`. See section 'Package sanity check' for further details
# Update packages with `apt full-upgrade`. Before accepting, check that no unexpected package changes are happening for installing/updating/removing.
# After the updates are completed, reboot the host with `reboot`
# Wait for the host to be rebooted. You can check Zabbix, ping, or trying to SSH into the host again to check.
# On Zabbix, go to 'Configuration' -> 'Hosts', and click on 'items' for the rebooted host.
# Search for 'reboot', select the checkbox for both items and click on 'Execute now'.
# Search for 'operating', select the checkbox for the item that has a trigger that uses it, and select 'Execugte now'.
# Go to 'Monitoring' -> 'Problems'. Check the checkbox for triggers that fired for this host. Expected are '<host> has been restarted' and 'Operating system description has changed'. Scroll to the bottom and click on 'Mass update'. In the modal, check the checkbox for 'close problem', 'acknowledge', and in the 'message' box write the reason the host was rebooted. For example 'host was rebooted due to kernel update'

== Package sanity check ==
Expected packages can be 'delftsolutions-*' for almost all hosts.
For Gitlab (runners), expected packages can also include the gitlab-ee package or gitlab-runner packages