# Devops 0
## Zadanie 1

1. Kiedy chcemy się upewnić, że nie ma żadnych ukrytych zależności/powiązań
2. Probelm z 'flaky/niestabilnymi' testami. Czasem fizyczne zakłócenia albo inne takie
3. Performance tests, testowanie niezależne od nas (wątki, wyścigi, losowość), testowanie cache'u (raz z raz bez)
3. Performance tests? Nwm czy coś jeszcze

Przykład na pytest
1. `--radom-order` https://pypi.org/project/pytest-random-order/
2. `--repeat` https://pypi.org/project/pytest-repeat/
3. `--count N` (-x opcjonalnie, do pierwszego failure)

## Zadanie 2

1. Obecne i historyczne zużycie?
2. Czy są plany na jakieś nowe ficzury, wzrost liczby użytkowników?
3. Czy jest jakaś sezonowość (micro/macro)? Np. na zimę dużo więcej użytkowników, czy tam w ciągu dnia
4. Czy są jakieś plany na zmianę architektury?
5. Jaki jest usecase? Jeśli się skaluje to może będzie trzeba brać to pod uwagę
6. Jakie wymagania (performance, cpu, gpu, cokolwiek)
7. Jaki jest budżet
8. Czy planujemy wzrost developerow, czy nowe projekty -> bo wiecej sie pojawia
9. Nowe testy, statyczne analizy

## Zadanie 3

1. Mapa key - value
2. Listy zaczynają się od `-`
3. Indent ma znaczenie - każdy indent to struktura
4. Są podstawowe typy string/int/boolean
5. Syntax z `|` i `>`
* `|` will include the newlines and any trailing spaces
* `>` will fold newlines to spaces
6. Komentarze `#`
7. Variable w {{ var }}

Jakieś problemy
* Białe znaki mają znaczenie
* True (false w odpowiedni sposób) -> system typów zepsuty
* trudny debug (nie pokazuje linijki)

1.7 == 1.70
1.7.0 != 1.70.0
Zapis liczb ósemkowo (0666 0o666) -> 0 na początku

More info https://docs.ansible.com/ansible/latest/reference_appendices/YAMLSyntax.html

## Zadanie 4

jinja2

W skrócie język do templatowania w pythonie do HTML.

https://pl.wikipedia.org/wiki/Jinja2

## Zadanie 5

Wszystko zaelży od skali (i usecase'ów), czasem to oznacza 1 fail na rok, a w innym przypadku 100k na sekundę

Będzie miało problem `100000 - 100000*.9999 = 10`

## Zadanie 6

Bigtable to rozproszony, trwały, posortowany map (klucz trzech wymiarów):
(row:string, column:string, timestamp:int64) -> string — tabelaryczny model, gdzie:
* row key: podstawowy klucz wiersza (służy do lokalności danych),
* column families: kolumny pogrupowane w rodziny (każda rodzina konfigurowana osobno),
* timestamp: wersjonowanie wartości (przechowywanie wielu wersji komórek).
Dane są sparse — wiele komórek może być pustych bez kosztu strukturalnego.

* Rozproszona baza danych od firmy na G (model kolumnowy)
https://static.googleusercontent.com/media/research.google.com/en//archive/bigtable-osdi06.pdf

Chat mówi: https://chatgpt.com/canvas/shared/68e6dc1a5a808191b7a96df50bf59974
nt tego paperka co na górze jest

## Zadanie 7

- na jaką skalę ma to być ficzur
- czy to będzie internal/external project
- kiedy ma być gotowy i czy deadline jest twardy
- jak nowa jest obecna baza kodu czy istnieje dokumentacja, czy jest od nowa (OBECNY STAN PROJEKTU)
- zależność od innych zespłów i czynników (czy trzeba pracować z USA)
- czy robić pipeline'y CI/CD czy można robić bez testów :DD
- Acceptance criteria
- jak ma działać biznesowo? co ma robić? jak wyglądać?

## Zadanie 8

możliwe wartości od 200ms do 2s
ppb że większe niż 200ms to jest 4%.

=== Skowi gada głupoty ===

20 -> pierwszy poziom
20 -> drugi poziom (1 specjalny wywołuje 20 zapytań)
Zakładamy, że są niezależne
P(że wolne) = 1/10^4 -> p
P(że żaden wolny) = (1 - p)^(20+20) = (1 - p)^40 = 0.99600779 -> X
P(że przynajmniej jeden wolny) = 1 - X = 0.00399221
Zatem ppb to około 0.4%

## Zadanie 9

* Narzędzie do wersjonowania katalogu `/etc`
* integracja np. z gitem
* śledzi zmiany po apt upgrade, yum update etc
* ułatwia rollback, historię itp
https://wiki.archlinux.org/title/Etckeeper