BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//pretalx//cfp.cfgmgmtcamp.org//2024//LWKL3U
BEGIN:VTIMEZONE
TZID:Europe/Brussels
BEGIN:STANDARD
DTSTART:20001029T030000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
TZNAME:CET
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:20000326T020000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3
TZNAME:CEST
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
UID:pretalx-2024-KYMVRP@cfp.cfgmgmtcamp.org
DTSTART;TZID=Europe/Brussels:20240206T155500
DTEND;TZID=Europe/Brussels:20240206T164500
DESCRIPTION:Back in the day in a IT company long ago\, where the BOFHs roam
 ed and the ITIL was strong. We used to keep long lists of CIs that used to
  enviably and hopelessly out of date. Because we either didnt care\, know 
 or bother keeping up to date. That was totally fine in a relatively static
  environment the IT company of long ago. We would have our yearly inventor
 y day and forget about it again.\n\nOf course we all use some form of infr
 astructure as code right now. Some of us might go as far that "if it isn't
  in code it doesnt exist"\,  but can we truly say that whatever is in the 
 OpenTofu state really is the only thing running? What about that recurring
  1$ in that dormant AWS account\, where is that coming from? How about the
  playground projects the CEO likes to play around with in his sparetime? o
 r that one time the opentofu destroy didnt exit cleanly and some resources
  weren't cleaned during that timeout\, did we really manually cleanup all 
 resources?
DTSTAMP:20260917T005948Z
LOCATION:D.Aud
SUMMARY:Cost reconciliation in a post CMDB world - Bram Vogelaar
URL:https://cfp.cfgmgmtcamp.org/2024/talk/KYMVRP/
END:VEVENT
BEGIN:VEVENT
UID:pretalx-2024-33PWEF@cfp.cfgmgmtcamp.org
DTSTART;TZID=Europe/Brussels:20240205T122500
DTEND;TZID=Europe/Brussels:20240205T123000
DESCRIPTION:Athletes\, Firemen and Doctors train everyday to be the best at
  their chosen profession. As engineers we spend much of our time getting s
 tuff to production and making sure our infrastructure doesn’t burn down 
 out right. We however spend very little time learning to understand and re
 spond to outages. Does our platform degrade in a graceful way or what does
  a high CPU load really mean? What can we learn from level 1 outages to be
  able to run our platforms more reliably.
DTSTAMP:20260917T005948Z
LOCATION:D.Aud
SUMMARY:a Pint size introduction to SLO - Bram Vogelaar
URL:https://cfp.cfgmgmtcamp.org/2024/talk/33PWEF/
END:VEVENT
BEGIN:VEVENT
UID:pretalx-2024-7LLPA8@cfp.cfgmgmtcamp.org
DTSTART;TZID=Europe/Brussels:20240205T140000
DTEND;TZID=Europe/Brussels:20240205T145000
DESCRIPTION:We all know the wall of illegible wall of small graphs\, that w
 e like to present to (senior) management and auditors as proof that we do 
 observability. It doesnt matter that the person ( and the associated knowl
 edge) has long since left the company\, nor that the dashboard doesnt auto
 refresh and still show the same data from when we turned on the monitoring
  PC.\n\nIn an ever changing IT landscape we deserve better than that. We s
 houldn't have to rely on the gut instinct of the senior engineer on deck a
 bout the general shape of the dashboard to know where to start fixing what
 ever it is that needs fixing.\n\nWe should aim to collect and present such
  information both from the it and business side that let a relatively inex
 perienced oncall engineer differentiate between a P1 incident and a major 
 client/customer/continet going to bed.\n\nWe should be telling beautiful s
 tories with data and dashboards in such a way that (even) management can p
 ull up global dashboard and can determine business relevant information li
 ke "is our advertisement campaign having any impact". We should also not b
 e afraid to have multiple dashboards that show different relevant informat
 ion to stack holders (e.g sales figures for management and links to runboo
 ks for engineers)\n\nhttps://www.slideshare.net/slideshows/scraping-metric
 s-for-fun-and-profit/266147160
DTSTAMP:20260917T005948Z
LOCATION:B.3.039
SUMMARY:Scraping metrics for fun and profit - Bram Vogelaar
URL:https://cfp.cfgmgmtcamp.org/2024/talk/7LLPA8/
END:VEVENT
END:VCALENDAR
