# Chmura i infrastruktura Infrastruktura, którą zespół potrafi utrzymać, zrozumieć i rozwijać. Dla firm i agencji, które prowadzą wiele stron i usług w chmurze, a koszty i ryzyko rosną szybciej niż zespół. ## Dla kogo ### Firmy z wieloma stronami i markami Kilkanaście lub kilkadziesiąt stron postawionych w różnych latach, przez różne agencje, na różnych hostingach. Marketing czeka na IT, IT nie wie, kto odpowiada za którą stronę, a każda aktualizacja to osobny projekt. Jeśli problemem jest też sam CMS i proces publikacji, zobacz [produkty i platformy cyfrowe](https://kol.ski/pl/produkty-cyfrowe). ### Zespoły, w których wdrożenia zależą od jednej osoby Jedna osoba zna hasła, serwery i kolejność kroków. Jej urlop zatrzymuje wdrożenia, a jej odejście byłoby incydentem. Dokumentacja istnieje głównie w jej głowie. ### Organizacje przed migracją lub przeglądem kosztów Rachunek za chmurę rośnie co miesiąc i nikt nie potrafi powiedzieć, co można wyłączyć. Albo planujesz przenosiny z serwera dedykowanego lub między chmurami i chcesz poznać zależności, zanim cokolwiek zostanie ruszone. ## Co zwykle znajdujemy Te same problemy powtarzają się w większości środowisk, które przeglądamy: - Maszyny działające całą dobę dla stron, które odwiedza kilkaset osób dziennie. - Panele administracyjne CMS dostępne publicznie, chronione tylko hasłem. - Dostępy nadane lata temu osobom i agencjom, które już nie współpracują. - Kopie zapasowe, których nikt nigdy nie próbował odtworzyć. - Każda strona skonfigurowana inaczej, więc nie da się ich aktualizować hurtowo. - Kilka kont rozliczeniowych i brak jednego miejsca, w którym widać cały koszt. Większość z nich da się usunąć bez przebudowy całości. Zaczynamy od tych, które najszybciej obniżają koszt lub ryzyko. Dwa ostatnie punkty to często także kwestia zgodności: kto ma dostęp do danych osobowych i na jakiej podstawie, czym zajmujemy się w ramach [digital compliance](https://kol.ski/pl#areas). ## Nad czym pracujemy ### Architektura i migracje Mapujemy usługi, dane i zależności, dobieramy architekturę docelową i planujemy przenosiny etapami. Każdy etap ma kryteria odbioru i możliwość powrotu, jeśli weryfikacja wykaże problem. ### Wdrożenia i utrzymanie Powtarzalne środowiska, CI/CD, monitoring, kopie zapasowe i procedury odtwarzania. Rutynowe czynności, które da się opisać krokami, zamieniamy w [automatyzacje](https://kol.ski/pl/ai-automatyzacja), żeby zespół wykonywał je bez ręcznej pracy. ### Koszty i wykorzystanie zasobów Sprawdzamy, co działa, po co działa i jak jest rozliczane. Dobór wielkości zasobów, publikacja statyczna i uruchamianie usług tylko wtedy, gdy są potrzebne, to możliwości oceniane na podstawie rzeczywistego użycia. ## Co zrobiliśmy wcześniej Doświadczenie [założycieli](https://kol.ski/pl/zalozyciele) z projektów realizowanych przed powstaniem spółki, bezpośrednio i we współpracy z agencjami, dla dużych organizacji i startupów. Więcej w sekcji [osiągnięcia](https://kol.ski/pl#experience). - Koszty infrastruktury i utrzymania niżej o 80% po przebudowie platformy, przy rosnącej liczbie stron, integracji i automatyzacji. - Ponad 100 maszyn wirtualnych: każda strona na własnej, izolowanej maszynie, która uruchamia się na czas pracy i sama wyłącza, gdy nikt jej nie potrzebuje. - Ponad 6 lat bez incydentu bezpieczeństwa na prowadzonych stronach: panel administracyjny za prywatnym tunelem i bramką logowania. - Ponad 250 projektów chmurowych w jednym modelu ról i uprawnień, z ponad 40 usługami Google Cloud i Firebase. - Kilkuosobowy zespół techniczny utrzymujący dziesiątki stron. Skala wynika z architektury, nie z liczby etatów. ## Przykład: wiele marek, jedna platforma Typowy punkt wyjścia i to, co z niego zbudowaliśmy. Nazwę klienta, liczby i szczegóły konfiguracji omawiamy na spotkaniu. ### Przed Wszystkie strony marek w jednym środowisku: wspólny serwer, wspólne hasła, jedna pozycja na fakturze. Awaria lub włamanie na jednej stronie zagrażało wszystkim, a każda aktualizacja wymagała okna serwisowego dla całości. ### Po Każda strona jako osobny projekt w Google Cloud: własna maszyna, własne uprawnienia, własny koszt widoczny na rachunku. Treść publikowana statycznie, panel CMS za prywatnym tunelem, maszyny włączane tylko na czas pracy redakcji. ### Wynik Koszty infrastruktury i utrzymania niżej o 80% przy rosnącej liczbie stron. Ponad 6 lat bez incydentu bezpieczeństwa. Jeden model ról i dostępów dla klienta, agencji i domów mediowych, utrzymywany przez kilkuosobowy zespół. ## Trzy kroki, każdy do zakończenia w dowolnym momencie ### 1. Bezpłatna konsultacja 30 minut online. Opowiadasz, co masz i co w tym boli. Mówimy, czy i jak możemy pomóc oraz co zrobilibyśmy najpierw. Bez przygotowań, bez dostępu do środowiska, bez zobowiązań. ### 2. Przegląd infrastruktury Stały zakres i stała cena ustalona przed startem. Do dwóch tygodni od otrzymania dostępu do odczytu. Na tym etapie niczego nie zmieniamy. Raport i omówienie z zespołem. ### 3. Wdrożenie Zmiany z raportu wdrażane etapami, z kryteriami odbioru i ceną ustaloną dla każdego etapu. Po każdym etapie decydujesz, czy idziemy dalej, czy przejmuje to Twój zespół. ## Co zawiera przegląd - Inwentaryzacja: usługi, maszyny, domeny, konta rozliczeniowe oraz kto ma do czego dostęp. - Koszty: co kosztuje ile i dlaczego; które pozycje można wyłączyć, zmniejszyć lub zamienić na publikację statyczną. - Ryzyka: pojedyncze punkty awarii, brak sprawdzonych kopii, publiczne panele, zależność od jednej osoby. - Plan: lista zmian uporządkowana według efektu i nakładu pracy, z szacunkiem oszczędności i proponowaną kolejnością. - Omówienie wyników z zespołem i decyzja, czy i co wdrażamy dalej. Tak wygląda fragment części kosztowej raportu. Dane są ilustracyjne, układ jest prawdziwy: | Pozycja | Stan obecny | Rekomendacja | Efekt | | --- | --- | --- | --- | | Strona firmowa, maszyna 4 vCPU | Działa całą dobę przy kilkuset odwiedzinach dziennie | Publikacja statyczna, maszyna tylko na czas edycji | Koszt maszyny niżej o około 90% | | Baza danych współdzielona przez 12 stron | Jedna instancja, awaria dotyka wszystkich | Osobna baza w projekcie każdej strony | Izolacja awarii i kosztów | | Panel CMS | Dostępny publicznie, logowanie hasłem | Prywatny tunel i logowanie kontem firmowym | Zamknięty wektor ataku | | Dostępy | 23 konta, 9 nieaktywnych, 3 współdzielone | Odebranie nieaktywnych, role zamiast kont współdzielonych | Uprawnienia możliwe do audytu | | Kopie zapasowe | Codzienne, nigdy nie odtwarzane | Test odtworzenia co kwartał, spisana procedura | Potwierdzony czas odtworzenia | Przegląd jest też pierwszym etapem migracji: inwentaryzacja i mapa zależności to to, czego i tak potrzebujesz, zanim cokolwiek przeniesiesz. ## Co zostaje po Twojej stronie Pracujemy w Twoich kontach chmurowych, na Twoich domenach i w Twoim repozytorium. Dostęp administracyjny pozostaje w firmie, a nie u wykonawcy. - Konfiguracja środowiska i procedury wdrażania zapisane jako kod, nie jako wiedza jednej osoby. - Dokumentacja operacyjna: co działa, gdzie, kto ma dostęp i jak to odtworzyć po awarii. - Uporządkowane uprawnienia dla zespołu, agencji i partnerów, z możliwością ich przeglądu w jednym miejscu. - Przekazanie wiedzy zespołowi, w razie potrzeby w formie [warsztatów](https://kol.ski/pl/szkolenia), albo ustalony miesięczny zakres dalszego utrzymania. ## Jak przebiega migracja Siedem kroków, zawsze w tej kolejności. Każdy ma kryterium przejścia, a obecne środowisko działa bez zmian do momentu przełączenia i zostaje potem jako kopia do powrotu. Przenosiliśmy strony i sklepy: WordPress i WooCommerce, Drupal, Joomla, Pimcore, autorskie CMS-y i platformy e-commerce agencji, między hostingami współdzielonymi, serwerami dedykowanymi i chmurami. ### 1. Inwentaryzacja domen i serwisów Wszystkie domeny i subdomeny, rekordy DNS, certyfikaty, strony, usługi i integracje: poczta, formularze, płatności, analityka, API. Kto za co płaci i kiedy co wygasa. Wynik: jedna lista, której dotąd nie było. ### 2. Audyt dostępu do kodu, baz i serwerów Kto ma dostęp do repozytoriów, paneli hostingu, baz danych, serwerów, rejestratora domen i DNS. Odzyskujemy to, co jest tylko u poprzedniego wykonawcy. Bez pełnego dostępu nie zaczynamy przenosin. ### 3. Kopie bezpieczeństwa Pełna kopia plików, baz i konfiguracji każdej strony przed jakąkolwiek zmianą, przechowywana poza oboma środowiskami. Odtworzenie z kopii sprawdzamy na środowisku testowym, nie zakładamy, że działa. ### 4. Przeniesienie infrastruktury Środowisko docelowe budowane obok obecnego, z konfiguracji zapisanej jako kod, w Twoich kontach. Strony uruchamiane pod adresami testowymi i przełączane partiami w ustalonym oknie, poza godzinami pracy zespołu. Powrót to przepięcie DNS, bo stare środowisko stoi nietknięte. ### 5. Weryfikacja stron, poczty i formularzy Lista kontrolna dla każdej strony: podstrony i przekierowania, logowanie do CMS, formularze z potwierdzeniem dostarczenia, poczta (rekordy MX, SPF, DKIM, DMARC), w sklepach koszyk i zamówienie testowe z płatnością, integracje, certyfikaty, wydajność. Wyniki w raporcie, nie w zdaniu „działa”. ### 6. Kontrola SEO po migracji Porównanie adresów przed i po, przekierowania 301 dla zmienionych, mapa strony, `robots.txt`, adresy kanoniczne, dane strukturalne. Search Console bez nowych błędów indeksowania, pozycje i ruch obserwowane przez kolejne tygodnie. ### 7. Dokumentacja i procedury awaryjne Co działa gdzie, kto ma dostęp, jak odtworzyć stronę z kopii, kogo i jak powiadomić. Przekazujemy w Twoim repozytorium razem z dostępami. Tak to wygląda: [przykładowa dokumentacja przekazania](https://kol.ski/pl/przekazanie-przyklad). ## Jak działa utrzymanie Utrzymanie zaczyna się po przeglądzie: wiemy, co przejmujemy, i mamy spisane, kto za co odpowiada. ### Przegląd przed przejęciem Nie przejmujemy odpowiedzialności za środowisko, którego nie znamy. Przegląd daje inwentaryzację, listę ryzyk i plan; zakres utrzymania i podział odpowiedzialności ustalamy na jego podstawie. ### Zgłoszenia i czas reakcji Zgłoszenie trafia do systemu, nie do skrzynki jednej osoby: powstaje ticket, alert idzie do osób na dyżurze, zaczyna się weryfikacja. Awaria krytyczna: telefon całodobowo, reakcja do 15 minut. Pozostałe zgłoszenia: mail lub formularz w godzinach 8–20, reakcja do godziny. Te czasy zapisujemy w umowie. ### Czego nie obiecujemy Czasu usunięcia awarii. Zależy od przyczyny, a obietnica bez pokrycia nic nie daje. Gwarantujemy informację o stanie w ustalonym czasie i, jako ścieżkę ostateczną, przywrócenie serwisu z kopii w czasie potwierdzonym testami odtwarzania. ### Monitoring, kopie i testy odtwarzania Monitoring dostępności i stanu z automatycznymi alertami. Kopie zapasowe z ustaloną retencją. Regularne testy odtworzenia ze spisaną procedurą, bo kopia, której nikt nie odtwarzał, nie jest kopią. ### Bez zależności od jednej osoby Konfiguracja i procedury zapisane jako kod w Twoich zasobach, dokumentacja operacyjna, dyżury dzielone między założycieli i partnerów. Zwykle dwie, trzy osoby na klienta, celowo: generaliści, nie specjaliści od jednego narzędzia. Ryzyko, które usuwamy u klientów, nie może istnieć po naszej stronie. ### Odpowiedzialność za błędy Macierz odpowiedzialności w umowie: infrastruktura, aktualizacje, kopie, monitoring, treści, usługi zewnętrzne, zmiany poza procesem. Błąd po naszej stronie usuwamy na własny koszt, razem z dodatkowymi elementami potrzebnymi do naprawy, w ramach naszego wynagrodzenia. Błąd po stronie zlecającego to jego odpowiedzialność, ale i wtedy pomagamy: dodatkowi specjaliści, dodatkowy audyt, plan naprawy. ## Technologia wynika z potrzeb Pracujemy z Google Cloud Platform, Firebase, Kubernetes, Linuksem i narzędziami CI/CD. Wybór zależy od obciążenia oraz zespołu, który będzie utrzymywał rozwiązanie. Niewielka strona statyczna i platforma z kilkoma usługami wymagają innych rozwiązań. Nie przenosimy do chmury na siłę: czasem najlepszym wynikiem jest wyłączenie połowy tego, co działa. Gdy gotowe narzędzie nie istnieje, budujemy je w ramach [R&D na zamówienie](https://kol.ski/pl#areas), jak panele do zarządzania maszynami czy publikację statyczną z CMS. ## FAQ ### Jesteście nową firmą? Spółka tak, od 2026 roku; praktyka nie. Jakub podpisuje umowy we własnym imieniu od 2009, prowadzi działalność od 2016, a od 2014 kieruje dużymi środowiskami cyfrowymi; Agata od ponad dziesięciu lat prowadzi projekty cyfrowe. Do spółki wnieśliśmy narzędzia i dokumentację z poprzedniej dekady umowami z przeniesieniem praw. Oś czasu jest na stronie [założycieli](https://kol.ski/pl/zalozyciele). ### Czy musimy wszystko przenosić? Nie. Często najlepszy wynik daje wyłączenie zbędnych zasobów i uporządkowanie dostępów w obecnym środowisku. Migracja jest jedną z opcji, nie punktem wyjścia. ### Czy stracimy kontrolę nad środowiskiem? Przeciwnie. Pracujemy w Twoich kontach, dokumentujemy każdy krok, a dostęp administracyjny pozostaje po Twojej stronie od pierwszego dnia. ### Co z obecną agencją lub działem IT? Możemy współpracować z obecnym zespołem albo przejąć wyraźnie określony fragment. Podział odpowiedzialności zapisujemy przed startem. ### Czy mała firma to dla Was za mało? Nie. Jedna strona i kilka usług to często najszybszy zwrot. Zakres dobieramy do wielkości środowiska, nie odwrotnie. ### Jak rozliczamy pracę? Pierwsza konsultacja: bezpłatna, 30 minut online. Przegląd: stała cena. Wdrożenia: etapy z kryteriami odbioru i ceną ustaloną dla każdego etapu. Utrzymanie: miesięczny zakres ustalany po przekazaniu. ### Co z danymi i poufnością? Umowę o poufności i powierzenie przetwarzania danych podpisujemy przed otrzymaniem dostępu. Dostęp jest imienny, ograniczony do zakresu prac i odbierany po ich zakończeniu. Zasady przetwarzania danych z formularza opisuje [polityka prywatności](https://kol.ski/pl/legal). ### Czy podacie referencje? Serwisy, które prowadzimy od lat, należą do organizacji, które traktują informację o dostawcy infrastruktury jako element własnego bezpieczeństwa, dlatego obowiązują nas umowy o poufności. Na spotkaniu omawiamy skalę i architekturę bez nazw, a za zgodą klienta organizujemy rozmowę referencyjną. Lista publicznych referencji jest w przygotowaniu. ### Co z awarią w nocy albo w weekend? Awarię krytyczną zgłaszasz telefonicznie, całodobowo, z reakcją do 15 minut. Zgłoszenia mailem lub formularzem obsługujemy w godzinach 8–20 z reakcją do godziny; te, które przyjdą w nocy, czekają do rana, chyba że monitoring wykryje awarię wcześniej i sam uruchomi alert. ### Czy doświadczenie opisane na stronie pochodzi z projektów obecnych założycieli? Tak. Wszystkie liczby i przykłady pochodzą z projektów, które Jakub i Agata prowadzili osobiście przed powstaniem spółki, bezpośrednio i we współpracy z agencjami. Nie opisujemy dorobku osób, których nie ma w zespole. ### Kto odpowiada finansowo za błędy podczas migracji? Za błąd po naszej stronie odpowiadamy my: naprawę i wszystko, co jest potrzebne do usunięcia skutków, wykonujemy na własny koszt, w ramach ustalonego wynagrodzenia. Nie jest to odpowiedzialność odszkodowawcza i mówimy to wprost przed podpisaniem umowy. Za błędy po stronie zlecającego odpowiada zlecający, ale pomagamy je usunąć, także szukając dodatkowych specjalistów i wykonując dodatkowe audyty. Dlatego migrację prowadzimy tak, żeby błąd nie był kosztowny: stare środowisko zostaje nietknięte do końca obserwacji, a powrót trwa minuty. ### Ile stron utrzymywaliście? Portfel stron kilkudziesięciu marek jednego klienta przez wiele lat i kilkanaście serwisów innych firm, razem z ich środowiskiem pomiarowym: Google Analytics, Tag Manager, konta reklamowe. Nazwy i liczby objęte poufnością omawiamy na spotkaniu. ### Czy sami odpowiadacie za hosting i infrastrukturę? Tak. Zakładaliśmy od zera organizacje w Google Cloud Platform, Google Marketing Platform i Google Workspace wraz z kontami rozliczeniowymi i odpowiadaliśmy za ciągłość ich działania. Konta należały do klienta, odpowiedzialność techniczna do nas. ### Czy zarządzacie WordPressem i innymi CMS-ami? Tak. Tworzymy strony od podstaw, audytujemy i przejmujemy po innych wykonawcach: WordPress, Drupal, Joomla, Pimcore, autorskie CMS-y agencji, platformy e-commerce. Strona, która jest u nas, jest naszą odpowiedzialnością: aktualizacje, kopie, monitoring, bezpieczeństwo. Najczęstszym celem migracji jest WordPress, bo znają go programiści, agencje i same firmy, więc nie uzależnia od jednego wykonawcy. ### Ile osób obsługuje jednego klienta? Zwykle dwie, trzy, celowo. Pracujemy z generalistami: full stack zamiast programisty jednego frameworka, sysops i devops dla GCP, Azure i AWS zamiast administratora jednej chmury, osoba, która otworzy Figmę, wdroży zmianę w WordPressie i poprowadzi rozmowę z klientem zamiast kierownika projektu od samych spotkań. Skalujemy zakresem i narzędziami, nie liczbą etatów. ### Jak wyglądały SLA i awarie u poprzednich klientów? Umowne SLA: godzina na reakcję; w praktyce reakcja w chwili zgłoszenia, dlatego dziś oferujemy 15 minut dla awarii krytycznych. Serwisy za CDN i u więcej niż jednego dostawcy, żeby awaria jednego elementu nie zatrzymywała reszty. W monitoringu i od klientów nie mieliśmy zgłoszeń niedostępności przez ostatnie lata. ## Przyjrzyjmy się Twojej infrastrukturze Napisz, ile stron i usług utrzymujesz, gdzie działają i co Cię w tym najbardziej niepokoi: koszt, ryzyko czy zależność od jednej osoby. Zaproponujemy termin. [Porozmawiajmy o projekcie](mailto:hi@kol.ski) · [Zarezerwuj 30 minut](https://calendar.app.google/CJxZPq3FqabCDMS59) · [Główne obszary](https://kol.ski/pl#areas)