Résumé
- Together Communication commercialise publiquement Together Cloud, l'hébergement partagé, les VPS et les serveurs dédiés, la colocation, les adresses fixes et les services de protection. L'entreprise indique que l'équipement des clients peut être placé dans ses centres de données, mais elle ne publie pas les sites, la conception électrique, l'inventaire des baies, l'architecture de stockage, les objectifs de reprise ou les niveaux de service standard qui sous-tendent cette offre.
- L'AS34008 porte le nom enregistré précis
Together-Communications-LTD-CLOUD-NETWORKet appartient à l'organisation RIPE de Together Communication LTD. RIPEstat l'a marqué comme non annoncé le 12 juillet 2026, sans préfixes actuels ni voisins observés; la dernière route largement observée en provenance de cet ASN remonte au 15 janvier 2019. - La même organisation enregistrée détient également l'AS42013, un réseau distinct et actif. RIPEstat a observé 13 préfixes IPv4, un préfixe IPv6, 5 120 adresses IPv4, une visibilité totale parmi les pairs déclarants et quatre voisins actuels. Il s'agit d'une preuve solide que Together exploite un réseau régional opérationnel, mais cela ne prouve pas que chaque charge de travail Together Cloud s'exécute sur AS42013 ou dans une installation particulière.
- PeeringDB et le Palestine Internet Exchange montrent l'AS42013 connecté à PSIX dans le bâtiment MTIT 01 à Ramallah sur un port de 1 Gbit/s. Les observations de routes publiques montrent également des chemins via AS8551 et AS1680. Ces faits soutiennent une connectivité en direct; ils n'établissent pas l'existence de sites de centres de données diversifiés, d'entrées de fibre physiquement séparées ou d'une capacité de basculement suffisante pour les clients hébergés.
- Les preuves d'exploitation réseau pour Together Communication dans son ensemble sont moyennes. Les preuves pour la surface réseau cloud attribuée à AS34008 sont négatives, et la confiance dans la résilience du cloud orienté client est faible. Les acheteurs ont besoin de connaître les emplacements précis des installations, la propriété des actifs, la séparation de l'alimentation et des transporteurs, les restaurations testées, l'escalade du support et les conditions d'exportation avant de considérer le service comme récupérable plutôt que simplement accessible.
L'offre est concrète; ses domaines de défaillance ne le sont pas
Lapage des services aux entreprisesde Together Communication est inhabituellement directe sur les produits qu'elle souhaite voir les entreprises acheter. Elle énumère Together Cloud, l'hébergement partagé, les serveurs privés virtuels, les serveurs dédiés, la colocation, les adresses IP fixes, les services de protection, les systèmes de communication et la connectivité SMS. L'hébergement partagé est présenté avec DirectAdmin, tandis que la description du cloud mentionne « NOD Controllers » et « VM NSX ». L'offre de colocation indique que les clients peuvent louer de l'espace dans les centres de données de l'entreprise pour leur propre équipement et bénéficier d'une connectivité rapide et d'adresses publiques.
Cela suffit pour identifier une proposition d'infrastructure réelle. Ce n'est pas une page de conseil générique qui ne promet que la transformation numérique. L'hébergement partagé nécessite des logiciels web et de messagerie, du stockage, un service de noms, des certificats et une administration des comptes. Un VPS nécessite un hôte de virtualisation, de la mémoire, une planification CPU, des interfaces réseau et des disques persistants. Un serveur dédié nécessite un châssis physique et un chemin de remplacement lorsqu'un composant tombe en panne.
La colocation nécessite des unités de rack, une distribution électrique, un refroidissement, un contrôle d'accès, des interconnexions et une personne autorisée à toucher la machine d'un client. Les adresses fixes nécessitent une gestion des adresses et une disponibilité continue des routes.
La page ne divulgue pas la carte physique sous-jacente à ces produits. Elle utilise le pluriel « centres de données » mais ne les nomme pas. Elle ne dit pas si les installations sont possédées, louées ou fournies par un autre opérateur. Il n'y a pas de décompte public des baies, des alimentations électriques, des générateurs, des batteries, des entrées de transporteurs ou du stock de serveurs disponibles. Il n'y a pas de distinction établie entre un site principal et un site de reprise.
Il n'existe pas non plus de calendrier public de niveau de service qui transforme « fiable » en un objectif de disponibilité mesurable, une fenêtre de réponse ou un remède.
Cette lacune n'est pas un verdict que le service échoue. C'est la raison pour laquelle le service doit être évalué de bas en haut. Un client ne récupère pas d'une panne cloud en pointant vers le mot cloud. La récupération provient d'une copie survivante des données, de calcul compatible, de routes joignables, d'identifiants fonctionnels, d'une capacité de réserve suffisante et de personnel capable de faire le changement. Together peut avoir ces capacités. Ses pages publiques ne les démontrent pas.
La distinction est particulièrement importante pour un fournisseur régional. Un opérateur local peut offrir des avantages précieux: support en arabe, ingénieurs de proximité, relations commerciales locales, courts chemins d'escalade et la possibilité de garder les charges de travail proches des utilisateurs. Ces forces peuvent être plus utiles à une petite entreprise palestinienne qu'un long catalogue de services hyperscale distants.
Mais la proximité concentre également le risque si la plateforme principale, la copie de sauvegarde, le transfert de transit et l'équipe de support partagent une seule ville, un seul bâtiment ou un seul contrat de fournisseur.
Deux ASN décrivent des surfaces d'exploitation différentes
La preuve publique la plus révélatrice commence par une contradiction apparente. Le nom d'entreprise attribué inclutCLOUD-NETWORK, et l'enregistrement de registre de l'AS34008lie ce nom exact à Together Communication LTD. L'enregistrement identifie l'organisation de l'entreprise commeORG-TCL42-RIPE, donne la Palestine comme pays et montre que l'ASN est attribué depuis mai 2015. Pourtant, la même page signale zéro route IPv4 et zéro route IPv6.
RIPEstat fournit une vue actuelle plus précise. Sonaperçu de l'AS34008a marqué le réseau comme non annoncé le 12 juillet 2026. Lavue des préfixes annoncésn'a retourné aucun préfixe pour les deux semaines précédentes. Lavue de l'état de routagen'a montré aucun espace d'adressage annoncé, aucun voisin observé et aucune visibilité parmi les pairs IPv4 ou IPv6 déclarants. Sa dernière route largement observée était 185.99.44.0/22 le 15 janvier 2019.
Les données historiques montrent que l'AS34008 a jadis été significatif sur le plan opérationnel. L'historique des préfixes à long terme de RIPEstatenregistre des préfixes liés à Together apparaissant de mai 2015 à janvier 2019. Ceux-ci incluaient des parties de 185.99.44.0/22 et, pendant une période, 185.61.20.0/22. L'enregistrement ressemble donc à une surface de routage retirée ou dormante, pas à un ASN simplement réservé et jamais utilisé.
La politique de routage enregistrée pour l'AS34008 nomme également plusieurs connexions prévues. Elle contient des déclarations d'importation et d'exportation impliquant des réseaux palestiniens et israéliens, y compris AS42013. Ces déclarations décrivent des objets de politique, pas des sessions actives. Elles ont été matériellement mises à jour pour la dernière fois des années avant la publication et contredisent l'absence de routes visibles. Un acheteur ne devrait pas compter une politique listée comme un chemin disponible tant qu'une observation de route actuelle ou un test opérateur ne le confirme.
Together a un autre ASN. L'entrée de membre RIPEnomme Together Communication LTD à Ramallah et répertorie la Palestine comme sa zone de service. Le même identifiant d'organisation apparaît sur AS42013, qui est enregistré sous le nom plus simpleTogether-Communication-LTD. Le 12 juillet, l'aperçu de l'AS42013 de RIPEstata marqué ce réseau annoncé.
Le contraste est frappant. L'AS34008 n'avait aucune route actuelle. L'état de routage de l'AS42013montrait 13 préfixes IPv4 couvrant 5 120 adresses, un préfixe IPv6, et une visibilité de tous les pairs RIPE RIS IPv4 et IPv6 déclarants au moment de la mesure. Saliste de préfixes annoncésincluait 2.58.132.0/22, 185.61.20.0/22, 185.99.44.0/22, 185.209.108.0/22, 91.229.247.0/24, 194.5.235.0/24, 212.47.82.0/23 et 2a0b:4d40::/29, ainsi que des routes plus spécifiques.
C'est une preuve solide que Together Communication exploite un réseau actif. Cela ne permet pas d'effacer la distinction entre les deux ASN. Un ASN peut séparer les produits, les politiques de routage, les époques ou les fonctions administratives. L'espace d'adressage autrefois émis par AS34008 peut maintenant être émis via AS42013 sans que chaque serveur ne soit déplacé. Une marque cloud peut utiliser le réseau actif tout en conservant un ancien nom d'ASN dans les registres publics. Elle peut également s'appuyer sur une infrastructure tierce. Les observations BGP publiques ne peuvent pas choisir parmi ces explications.
La conclusion correcte est étroite: l'organisation derrière l'entité attribuée reste visiblement active via un ASN distinct, tandis que la surface précise AS34008 est dormante dans la table de routage mondiale. Les clients devraient demander à Together quel ASN porte désormais Together Cloud, quels préfixes contiennent les charges de travail hébergées, et si AS34008 est conservé pour une utilisation future, une administration héritée ou une autre fin. Une réponse claire résoudrait une ambiguïté que les données de routage seules ne peuvent lever.
Un site web d'entreprise actif est un signal opérationnel, pas un audit cloud
Les domaines publics de Together ajoutent une autre pièce de preuve. À la publication,together.psse résolvait en 185.209.108.171 ettogether-pal.comse résolvait en 185.209.108.18. Les deux adresses se situent dans 185.209.108.0/22, l'un des blocs émis par AS42013. Le site web public utilise donc l'espace d'adressage routé par Together. C'est un signe direct que le réseau actif transporte au moins un service de l'entreprise.
Le signal a des limites. Une adresse de site web ne révèle pas si les instances VPS des clients occupent la même plateforme. Elle ne montre pas si le serveur web est physique ou virtuel, s'il est dans une baie Together ou une baie fournisseur, ou si le site a une réplique. Elle ne dit rien du nombre de clients d'hébergement payants ou de l'état de leurs sauvegardes. Elle prouve la joignabilité d'un point d'extrémité public, pas la conception du cloud commercial.
Lesite weba également illustré pourquoi les petits détails opérationnels comptent. Le 12 juillet, son point d'extrémité HTTPS présentait un certificat générique pour*.together.psdont la validité déclarée se terminait le 24 juin 2026. Les clients standards rejetaient la connexion parce que le certificat n'était plus valide, même si le serveur web retournait toujours le site lorsque la vérification de certificat était contournée. C'est une observation limitée dans le temps et qui pourrait être corrigée à tout moment. Elle ne doit pas être gonflée en un jugement sur l'ensemble de la plateforme.
Elle est néanmoins pertinente. Le renouvellement de certificat est une tâche de fiabilité modeste mais réelle. Un certificat expiré peut rendre un service fonctionnel indisponible pour les utilisateurs et les clients automatisés. Il peut interrompre les pages de paiement, les portails d'administration, les rappels de surveillance et les intégrations logicielles. L'événement ne nécessite pas une panne de baie ou une coupure de fibre; il nécessite un manque de propriété dans une tâche de maintenance récurrente.
Pour un acheteur d'hébergement, la question pratique n'est pas de savoir si un certificat public a expiré. C'est comment l'expiration, le renouvellement de domaine, le service de noms et les secrets d'application sont surveillés à travers les services clients. Les alertes sont-elles envoyées à une file d'attente dotée en personnel plutôt qu'à la boîte mail d'une seule personne? Un second ingénieur peut-il renouveler un certificat? Les identifiants sont-ils disponibles pendant un incident? Le service distingue-t-il la disponibilité de l'infrastructure de la disponibilité applicative dans ses engagements?
Une baie peut être alimentée et une route peut être saine tandis que les clients ne peuvent toujours pas établir une connexion sécurisée.
Ramallah est visible; le placement physique du cloud ne l'est pas
Plusieurs sources indiquent Ramallah comme centre opérationnel de Together. RIPE répertorie la rue principale Neleen à Ramallah. Lapage de contactde Together donne le bâtiment Al-Ramouni à Ramallah. Sonhistorique d'entrepriseindique que l'entreprise a commencé comme une initiative desservant les villages à l'ouest de Ramallah, a utilisé Al-Midya comme hub principal, et a ensuite étendu la couverture fibre et sans fil à travers plus de zones.
L'association d'installation la plus claire et indépendamment visible appartient à la connexion d'échange de l'AS42013.PeeringDBrépertorie Together au Palestine Internet Exchange, ou PSIX, sur un port de 1 Gbit/s, avec l'adresse IPv4 185.153.162.4 et l'adresse IPv6 2a07:8780:ffff:1::4. Il place cette connexion au bâtiment MTIT 01 à Ramallah. Laliste de membres PSIXmontre indépendamment AS42013 avec les mêmes adresses d'échange et une capacité de 1 Gbit/s.
Cela établit une présence réseau à un emplacement d'interconnexion nommé. Cela n'établit pas que les serveurs clients de Together sont dans ce bâtiment. Un port d'échange peut être atteint directement depuis l'équipement dans l'installation ou via un transport depuis un autre site. Un réseau peut appairer dans un bâtiment tout en hébergeant le calcul ailleurs. Inversement, une entreprise peut placer à la fois le routage et le calcul dans la même installation. Les registres publics ne disent pas quel arrangement s'applique.
La distinction importe parce qu'un nom de lieu n'est pas une carte de domaine de défaillance. Si la plateforme cloud et la connexion PSIX sont dans un seul bâtiment, un incident d'alimentation, de refroidissement, d'accès ou de bâtiment pourrait affecter à la fois l'hébergement local et l'interconnexion locale. S'ils sont dans des sites séparés connectés par fibre, le chemin fibre et l'équipement de transport deviennent des dépendances. Si les sauvegardes sont dans une deuxième salle du même bâtiment, elles protègent contre la défaillance de disque mais pas contre la perte du site.
Letraqueur IXP de l'Internet Societya rapporté 20 membres PSIX et 56 Gbit/s de capacité totale des membres en mai 2026. Cela indique un échange local significatif, pas un lien isolé à deux réseaux. L'appairage local peut garder le trafic approprié à l'intérieur de la Palestine, réduire la dépendance au transit international pour ces destinations et améliorer la latence. Le Ministère a également décrit PSIX comme un moyen de connecter les réseaux locaux plus directement et de réduire les coûts de ligne internationale.
Un échange n'est pas un substitut d'urgence pour l'Internet entier. Un site web client a toujours besoin de routes vers les utilisateurs et services qui n'appairent pas localement. Les dépôts logiciels, les destinations de sauvegarde distantes, les fournisseurs de paiement, les services de certificats et les clients mondiaux peuvent tous nécessiter un transit amont. PSIX peut améliorer le chemin local tandis que la connectivité internationale reste une dépendance séparée.
Together devrait donc pouvoir répondre à deux questions de localisation séparément. Où s'exécutent le calcul de production et le stockage principal? Où s'exécutent les transferts de routage et d'échange? La réponse devrait inclure la copie de reprise, pas seulement la baie principale. Sans cette carte, « hébergé localement » peut décrire la géographie légale tout en dissimulant un seul domaine de défaillance physique.
La diversité de transit est visible au niveau du routage, mais pas au niveau des conduits
Lavue des voisins de l'AS42013de RIPEstat montrait quatre voisins observés le 12 juillet. AS8551 et AS1680 apparaissaient du côté fournisseur des chemins, tandis que AS12975 et AS47546 apparaissaient du côté client. La politique enregistrée de AS42013 nomme également AS8551 et AS1680 comme réseaux à partir desquels il accepte les routes. Cela soutient la présence de plus d'un chemin externe au niveau BGP.
Les deux réseaux fournisseurs visibles sont exploités par Bezeq International et Cellcom Fixed Line Communication respectivement. Leur présence compte parce que la connectivité Internet palestinienne a longtemps fonctionné sous des contraintes géographiques et réglementaires inhabituelles. L'évaluation de l'économie numérique palestinienne de la Banque mondialedécrit des restrictions affectant les importations d'équipement, le spectre et le déploiement d'infrastructure. Ces conditions peuvent influencer les délais de matériel, les options de route et la vitesse à laquelle l'équipement endommagé ou obsolète est remplacé.
Deux ASN fournisseurs ne signifient pas automatiquement un transit résilient. Ils pourraient entrer dans le même bâtiment par le même conduit. Ils pourraient partager un segment longue distance. Les deux sessions pourraient se terminer sur un seul routeur de bordure, un seul commutateur ou une seule alimentation électrique. Un chemin pourrait être une sauvegarde de faible capacité incapable d'absorber la demande normale. La politique de routage pourrait également préférer un fournisseur si fortement que le basculement fonctionne en sortie mais pas en entrée.
L'entrée PeeringDB de Together donne à l'ensemble du réseau un niveau de trafic autodéclaré de 10-20 Gbit/s et qualifie son trafic d'équilibré. Elle liste également 5 000 préfixes IPv4 et 500 préfixes IPv6, des chiffres qui ne s'alignent pas naturellement avec le routage observé et semblent utiliser une signification différente des préfixes annoncés globalement. Les détails généraux du réseau de la page ont été mis à jour pour la dernière fois en 2022, tandis que des parties des informations d'appairage ont été mises à jour en 2023.
Ces champs doivent être traités comme des données de profil fournies par l'opérateur, pas comme une capacité auditée actuelle.
Le port PSIX de 1 Gbit/s est plus concret, mais ce n'est qu'un seul port à un seul échange. Il ne peut pas transporter 10-20 Gbit/s par lui-même. Ce n'est pas une contradiction si la plupart du trafic utilise le transit payant et que seul le trafic local utilise PSIX. Cela montre pourquoi la capacité doit être mesurée par chemin. Une bande de trafic totale dit peu de ce qui reste utilisable quand un amont, un routeur, une interconnexion ou un port d'échange tombe en panne.
Une revue de transit crédible demanderait le débit engagé et physique de chaque transfert, l'utilisation normale et de pointe, le temps de reconvergence attendu et le résultat du dernier exercice de basculement. Elle demanderait si les transporteurs utilisent des entrées indépendantes et s'ils restent indépendants au-delà du bâtiment. Elle demanderait également si le support et la surveillance peuvent atteindre la plateforme via un chemin de gestion séparé lorsque le trafic client est perturbé.
La sécurité du routage mérite une lecture tout aussi bornée. Plusieurs préfixes AS42013 ont des autorisations d'origine de route valides, et la route IPv6 active est largement visible. La validation RPKI aide les réseaux entités à rejeter une origine non autorisée. Elle n'empêche pas un routeur correctement autorisé d'annoncer la mauvaise route plus spécifique, ni ne maintient un bordure hors tension en ligne. C'est un contrôle dans la couche de routage, pas une déclaration sur les serveurs, le stockage ou le personnel.
« Capacité » a besoin d'une unité, d'un emplacement et d'une condition de défaillance
Lapage à proposde Together dit que l'entreprise est passée d'un service de données de 30 mégaoctets à plus de 100 gigaoctets de « capacité de données ». Le langage n'identifie pas si cela signifie un débit, un volume, le trafic transporté sur une période ou autre chose. La page affiche également des revendications de plus de 77 tours, plus de 300 000 utilisateurs, plus de 89 entreprises et un service à travers 17 villes.
Ces chiffres décrivent l'ambition et l'échelle dans l'activité d'accès. Ils ne fournissent pas une mesure utilisable du calcul hébergé. Un client VPS a besoin de connaître le CPU, la mémoire, les performances de stockage et le débit réseau disponibles. Un client de colocation a besoin de la puissance par baie, de la charge thermique permise, de la disponibilité des interconnexions et de l'espace pour la croissance. Un client de sauvegarde a besoin de la capacité retenue, de la fréquence de copie et de la bande passante de restauration. Un nombre sans unité et sans condition de défaillance ne peut répondre à aucune de ces questions.
La capacité installée et la capacité utilisable sont différentes. Une plateforme peut avoir 100 cœurs physiques mais en réserver certains pour l'hôte, la réplication et le basculement. Une baie de stockage peut avoir un grand total brut mais perdre un espace substantiel à cause de la mise en miroir, de la parité, des instantanés et des exigences d'espace libre. Une liaison montante de 10 Gbit/s peut être partagée par de nombreux locataires, limitée par un engagement amont ou étranglée par un pare-feu. Un second site peut exister mais avoir trop peu de calcul de rechange pour absorber le site principal.
Le chiffre de capacité le plus utile est ce qui peut encore être fourni après la plus grande défaillance crédible. Si un hôte tombe en panne, chaque VPS affecté peut-il redémarrer ailleurs sans évincer une autre charge de travail? Si un contrôleur de stockage tombe en panne, le contrôleur survivant maintient-il le taux d'entrée/sortie requis? Si un fournisseur de transit disparaît à l'heure la plus chargée, les liaisons restantes peuvent-elles transporter le trafic de production et de réplication? Si le site principal est indisponible, quels services sont restaurés en premier et lesquels attendent le matériel?
C'est également là que l'économie de l'hébergement devient physique. Garder des serveurs, disques, alimentations et optiques de rechange inactifs coûte de l'argent. Réserver une capacité de basculement abaisse l'utilisation moyenne. Un second site ajoute le loyer, l'alimentation, le transit et l'accès du personnel. De nombreux fournisseurs vendent donc un service de base qui protège contre les défaillances courantes de composants tout en facturant séparément une récupération plus forte. C'est raisonnable si la limite est explicite.
Cela devient dangereux lorsqu'un client suppose que « cloud » inclut la continuité au niveau du site que le prix n'a jamais financée.
Together ne publie aucun catalogue d'instances standard, aucune politique de sursouscription ou de niveau de récupération. Un client devrait demander ces conditions avant de comparer les prix. Le VPS mensuel le moins cher peut être approprié pour un frontal web remplaçable. Il n'est pas automatiquement adapté pour la seule copie d'un système comptable, d'un dossier patient, d'un service municipal ou de l'historique des commandes d'un détaillant.
Les baies transforment les promesses logicielles en obligations de réparation
Chaque produit Together Cloud atteint finalement un composant physique. Une machine virtuelle s'exécute sur des processeurs et de la mémoire. Ses disques dépendent de périphériques et de contrôleurs de stockage. Le trafic réseau traverse des cartes d'interface, des commutateurs, des optiques et des routeurs. Tous ces dispositifs dépendent de l'alimentation, du refroidissement et du micrologiciel. La virtualisation change la façon dont les ressources sont allouées; elle n'abolit pas la défaillance matérielle.
L'entreprise ne publie pas d'inventaire matériel ni de politique de pièces de rechange. Cela laisse une question pratique pour chaque produit. Pour l'hébergement partagé, un compte peut-il être restauré sur un autre serveur, et combien de temps cela prend-il? Pour un VPS, la haute disponibilité redémarre-t-elle la machine sur un autre hôte automatiquement, ou le remplacement est-il manuel? Pour un serveur dédié, existe-t-il un châssis de rechange correspondant, ou faut-il commander un composant? Pour la colocation, Together stocke-t-il seulement des pièces réseau, laissant le client responsable de son propre matériel serveur?
Les conditions d'importation en font plus qu'un problème théorique d'approvisionnement. La Banque mondiale a identifié à plusieurs reprises les restrictions sur l'équipement TIC comme une contrainte sur l'infrastructure numérique palestinienne. Un disque ou une alimentation défaillant est un incident court si une pièce de rechange approuvée est sur l'étagère. Cela peut devenir une panne beaucoup plus longue si la pièce doit traverser une chaîne d'approvisionnement contrainte, si le modèle exact est indisponible, ou si un remplacement nécessite une fenêtre de maintenance et l'approbation du client.
Le stock de pièces de rechange vieillit également. Des disques conservés trop longtemps peuvent ne pas correspondre au micrologiciel ou à la capacité d'une baie. Une carte mère de remplacement peut nécessiter une révision de processeur différente. Une optique qui s'adapte mécaniquement peut ne pas être acceptée par un commutateur. Les bons opérateurs suivent donc la compatibilité, testent le stock et planifient le remplacement du cycle de vie avant que l'équipement ne devienne difficile à supporter.
Les mains distantes sont la moitié humaine de la baie. Quelqu'un doit identifier le bon châssis, suivre les règles d'accès, déplacer un câble sans déranger le locataire adjacent et enregistrer le changement. Dans une petite opération régionale, quelques ingénieurs expérimentés peuvent détenir une grande partie de cette connaissance. Le service est plus fort lorsque les cartes de baie, les étiquettes, l'accès console et les enregistrements de changement permettent à une autre personne autorisée d'agir en toute sécurité.
L'analyse des pannes 2024 de l'Uptime Institutea constaté que l'alimentation restait la cause la plus commune des pannes de centre de données graves et sévères, tandis que les problèmes réseau étaient la plus grande cause unique de pannes de service IT. Elle a également rapporté que de nombreux incidents graves auraient pu être évités grâce à une meilleure gestion, des procédures et une configuration. Ces constatations mondiales ne décrivent pas Together spécifiquement. Elles montrent pourquoi une revue d'hébergement doit couvrir la maintenance et les personnes en plus des comptages d'équipement.
La redondance électrique doit survivre à la maintenance, pas seulement à une interruption de service public
Aucune page publique de Together ne décrit les alimentations électriques, les onduleurs, les batteries, les générateurs ou le carburant. L'absence ne signifie pas que ces systèmes sont manquants. Cela signifie que les clients ne peuvent pas savoir à quel événement électrique le service est conçu pour survivre.
Un seul onduleur peut combler une courte interruption tout en restant un point de défaillance unique. Deux unités d'onduleur n'aident que si chacune peut porter la charge requise et que la distribution en aval reste séparée. Un générateur fournit une plus longue autonomie seulement s'il démarre, a du carburant utilisable, peut être ravitaillé dans les conditions locales et ne partage pas un chemin de tableau électrique défaillant. Les alimentations doubles dans un serveur ajoutent peu si les deux sont branchées sur une seule unité de distribution.
La maintenance est la condition révélatrice. Un onduleur, un générateur, un panneau de disjoncteurs ou une unité de refroidissement peuvent-ils être mis hors service sans arrêter les baies clients? La maintenance est-elle annoncée, et le client sait-il si la redondance est temporairement réduite? Les batteries sont-elles testées en charge? Le générateur a-t-il porté la charge réelle de l'installation plutôt que seulement démarré sans charge?
Le refroidissement a la même structure. Une salle peut avoir plusieurs unités de climatisation mais une capacité insuffisante après que l'une est hors ligne. Un chemin de flux d'air bloqué peut surchauffer une baie tandis que la température ambiante semble acceptable. Le calcul ou le stockage dense peut dépasser les hypothèses de conception d'une salle plus ancienne. Les alarmes de température et d'humidité ont besoin d'un chemin de réponse qui fonctionne en dehors des heures de bureau.
Pour les clients de colocation, la limite de puissance devrait être écrite dans la commande. Le fournisseur contrôle l'alimentation et la distribution de l'installation; le client peut contrôler les alimentations d'équipement et la disposition en baie. Le contrat devrait indiquer la puissance incluse, les pics autorisés, le niveau de redondance, le préavis de maintenance et le remède. Sans ces détails, « espace de baie » dissimule la ressource la plus susceptible de déterminer si la baie reste en ligne.
La sauvegarde n'est pas une récupération tant qu'une charge de travail n'a pas été restaurée
La page entreprise publique de Together décrit le stockage et l'hébergement mais ne publie pas de conception de sauvegarde. Elle ne dit pas si un VPS inclut des instantanés, si les comptes d'hébergement partagé reçoivent des copies hors site, combien de temps les copies sont conservées, si les sauvegardes sont immuables ou comment les clients demandent une restauration. Il n'y a pas d'objectif de point de récupération ou d'objectif de temps de récupération public.
Cette omission affecte l'interprétation de chaque service. Un instantané sur la même baie peut aider à inverser un changement accidentel mais peut disparaître avec la baie. La réplication peut garder une seconde copie à jour, mais elle peut aussi répliquer la suppression, la corruption ou un rançongiciel. Une sauvegarde hors site protège contre la perte de l'installation principale seulement si le second emplacement est indépendant et joignable. Une copie détenue par le client améliore la résilience à la sortie du fournisseur mais nécessite un chiffrement, la garde des clés et des tests réguliers.
Lesconseils sur les rançongiciels de la CISArecommandent des sauvegardes chiffrées hors ligne, des tests de restauration réguliers et une attention à la responsabilité du fournisseur cloud. Ils notent également la valeur d'environnements séparés et d'images système conservées. Ce sont des conseils généraux, pas une preuve des contrôles de Together. Ils fournissent une référence utile pour ce qu'un client devrait demander.
Le chemin de restauration devrait être testé à la bonne échelle. Récupérer un petit fichier prouve qu'un dépôt peut retourner un objet. Cela ne prouve pas qu'une base de données peut être restaurée de manière cohérente, qu'un VPS complet peut démarrer, que les règles réseau peuvent être reconstruites ou que tous les systèmes critiques peuvent revenir dans le temps promis. Un exercice au niveau du site devrait inclure l'identité, le service de noms, les certificats, la configuration du pare-feu, les dépendances applicatives et suffisamment de bande passante pour déplacer les données.
Les clients ont également besoin de savoir qui initie une restauration. Si le portail est indisponible, y a-t-il une escalade téléphonique? Comment la demande est-elle authentifiée pour qu'un attaquant ne puisse pas ordonner un retour en arrière destructeur? Qui décide quel point dans le temps est sûr? La restauration écrase-t-elle la seule copie survivante? Ce sont des questions opérationnelles, pas des fonctionnalités premium.
Une revendication de récupération persuasive de Together inclurait l'emplacement et l'isolement de chaque copie, l'âge de la dernière sauvegarde utilisable, le temps pris par la dernière restauration complète et la capacité disponible sur le site de reprise. Jusqu'à ce que ces faits soient fournis, la sauvegarde devrait être traitée comme une option non vérifiée plutôt que comme une propriété supposée du cloud.
L'hébergement local peut améliorer la souveraineté tout en augmentant la concentration
La localité des données est une raison plausible de choisir Together. Une entreprise palestinienne peut vouloir une faible latence vers les utilisateurs locaux, un support local, des contrats familiers et une réponse claire sur où ses enregistrements résident. Les agences publiques et les organisations réglementées peuvent accorder une valeur particulière à garder les données principales sous juridiction palestinienne.
Le contexte politique renforce cet intérêt. L'évaluationde la Banque mondiale a décrit une préférence du gouvernement palestinien pour un cloud privé avec des données conservées à l'intérieur de ses frontières et un emplacement de reprise après sinistre potentiellement à l'étranger. Unavis plus récent de stratégie cloud du gouvernementplace la souveraineté des données et la résilience opérationnelle parmi les objectifs d'une stratégie d'hébergement unifiée. Ce sont des plans du secteur public, pas des exigences imposées à Together ni une preuve que ses services les satisfont.
La localité doit être définie composant par composant. Les disques de production peuvent être locaux tandis que les sauvegardes sont à l'étranger. Les journaux peuvent être envoyés à un service de sécurité étranger. Le filtrage des e-mails, le service de noms de domaine, les mises à jour logicielles, la surveillance et les systèmes de support peuvent traverser les frontières. Un fournisseur peut administrer un serveur local via des services hébergés ailleurs.
« Les données restent en Palestine » n'a donc de sens que lorsque le contrat identifie les données de production, les répliques, les sauvegardes, les métadonnées, l'accès de support et les copies de suppression.
La localité peut aussi augmenter le risque de concentration. Si la production et la sauvegarde sont gardées proches l'une de l'autre pour satisfaire une préférence de localisation stricte, le même événement régional d'alimentation, de connectivité ou d'accès peut affecter les deux. Une copie distante peut améliorer la reprise après sinistre tout en créant une autre frontière légale et de fournisseur. Il n'y a pas de réponse universelle. Le client doit décider quelles données peuvent partir, sous quel chiffrement et contrôle, et quelle défaillance importe le plus.
L'absence de noms de sites publiés rend cette décision plus difficile. Together devrait divulguer au moins le pays et la ville des emplacements de production, de sauvegarde et de gestion sous confidentialité si nécessaire. Il devrait identifier tout sous-traitant qui peut stocker ou accéder au contenu client. Il devrait également indiquer comment les données sont effacées des systèmes actifs, des sauvegardes et des supports retirés après résiliation.
La profondeur du support fait partie de la capacité disponible
Together se présente à la fois comme opérateur de réseau et fournisseur de services. Cela peut simplifier l'escalade parce que la même organisation peut voir le serveur hébergé et la route qui le transporte. Cela peut aussi placer plusieurs responsabilités sur les mêmes ingénieurs. Un incident d'accès généralisé peut générer des appels de clients résidentiels, professionnels, d'hébergement et de colocation à la fois, précisément quand le personnel réseau est le plus occupé.
Lapage de contactoffre des détails de contact commerciaux, un formulaire web et une présence téléphonique publique. PeeringDB publie un e-mail d'opérations réseau pour AS42013. Ce sont des signes de canaux de support joignables. Ils ne décrivent pas les heures, les niveaux de sévérité, les cibles de réponse, les rôles d'escalade nommés ou le personnel la nuit et les jours fériés.
Les promesses de support devraient distinguer la réponse de la réparation. Un accusé de réception en 15 minutes ne signifie pas qu'un serveur défaillant revient en 15 minutes. Le temps de réparation dépend du diagnostic, de l'accès au site, des pièces de rechange, de l'état de la sauvegarde et de l'autorité d'agir. Un client devrait demander quand l'horloge démarre, quels événements l'arrêtent et quel remède s'applique si la cible est manquée.
La concentration des connaissances est un autre risque. Qui peut accéder à l'hyperviseur, au stockage, aux routeurs, au système de sauvegarde et à l'installation? Au moins deux personnes sont-elles autorisées pour chaque tâche critique? Les identifiants d'urgence sont-ils protégés mais disponibles? Un autre ingénieur peut-il reconstruire un réseau de locataire à partir de la configuration documentée? Le client détient-il ses propres identifiants administrateur et clés de chiffrement le cas échéant?
La conception de support la plus forte fournit également un chemin de communication indépendant. Si la connectivité Together est en panne, une page de statut ou une hotline hébergée sur le même réseau peut disparaître avec elle. Les clients ont besoin d'un numéro, d'un canal de statut externe ou d'une escalade nommée qui reste joignable quand la plateforme principale ne l'est pas.
La facturation et les contrats fournisseurs peuvent créer des pannes sans matériel cassé
La pile physique se trouve à l'intérieur d'une pile commerciale. Together peut posséder certains équipements, louer de l'espace de baie, acheter du transit, concéder sous licence des logiciels de virtualisation et de panneau de contrôle, et obtenir des domaines ou certificats d'autres fournisseurs. Un renouvellement manqué, une facture contestée ou un contrat résilié peut interrompre le service même si chaque serveur reste sain.
Les clients ont besoin de savoir quelles dépendances peuvent suspendre leur charge de travail. Le VPS s'arrête-t-il immédiatement après un paiement manqué, et les données sont-elles conservées pendant une période de grâce? Une défaillance de licence logicielle peut-elle empêcher la gestion ou seulement le provisionnement de nouvelles ressources? Together a-t-il le droit de déplacer une charge de travail entre les installations? Quel préavis est donné avant qu'un produit ne soit retiré ou qu'un fournisseur ne change?
Les pages publiques de l'entreprise ne fournissent pas de conditions cloud standard, d'accord de niveau de service ou de calendrier de sortie. Cela rend l'examen individuel du contrat essentiel. L'accord devrait identifier la propriété des données, l'utilisation acceptable, les droits de suspension, la notification de violation, la responsabilité de sauvegarde, les heures de support, la maintenance, la responsabilité, les remèdes et l'assistance à la résiliation.
La colocation ajoute une division spéciale. Together peut fournir l'espace, l'alimentation et le réseau tandis que le client possède le serveur. Si le client cesse de payer, qui peut entrer dans l'installation et récupérer l'équipement? Si Together change d'installation, qui paie la migration et le temps d'arrêt? Si un disque tombe en panne, Together peut-il le remplacer, et à partir de quel stock? Ces questions déterminent si la propriété aide à la récupération ou se contente de déplacer la responsabilité.
La portabilité est le dernier test de résilience
Un service hébergé n'est pas entièrement récupérable si la seule copie ne peut s'exécuter que sous le contrôle du fournisseur actuel. Lesrecommandations cloud du NISTtraitent la portabilité de la charge de travail et les interfaces standard comme des limites importantes à la dépendance envers le fournisseur. Pour les clients de Together, la portabilité devrait être testée avant un incident, pas découverte pendant la résiliation.
L'hébergement partagé peut être portable en tant que fichiers de site web, bases de données, boîtes aux lettres et enregistrements DNS, mais les formats du panneau de contrôle peuvent compliquer un déplacement. Un VPS peut être exportable en tant qu'image de disque virtuel, mais l'image peut nécessiter des pilotes, micrologiciels ou configurations réseau différents ailleurs. Un serveur dédié peut contenir des données ordinaires mais dépendre d'une application sous licence liée à son matériel. L'équipement de colocation est physiquement portable mais peut utiliser des adresses qui ne peuvent pas être déplacées vers le fournisseur suivant.
Le plan de migration devrait spécifier le format, le temps et le coût. Un client peut-il télécharger une copie actuelle sans ouvrir un ticket de support? Y a-t-il des frais de sortie ou une limite de bande passante? Together fournira-t-il la cohérence de la base de données et un transfert delta final? Combien de temps les données et les sauvegardes sont-elles conservées après la sortie? Le client peut-il garder ses adresses, ou les règles DNS et de pare-feu doivent-elles changer?
L'AS34008 dormant rend cette question concrète. L'arrangement réseau de Together a changé auparavant: les préfixes visibles depuis AS34008 jusqu'en janvier 2019 sont maintenant associés à la surface active AS42013. Cela a pu être une transition de routage en douceur. Cela démontre néanmoins que les identifiants et les chemins d'origine peuvent changer pendant que l'entreprise continue. Les systèmes clients devraient pouvoir survivre au prochain changement sans dépendre d'un historique non documenté.
Un bon exercice de sortie peut être petit. Exporter un VPS représentatif, le restaurer dans un environnement indépendant, mettre à jour un nom DNS de test et confirmer que l'application fonctionne. Récupérer un compte d'hébergement partagé sans le panneau de contrôle d'origine. Récupérer une sauvegarde en utilisant des identifiants détenus par le client. Enregistrer le temps et les dépendances manquantes. L'exercice transforme la portabilité d'une phrase contractuelle en preuve.
Ce que les preuves actuelles peuvent et ne peuvent pas soutenir
Together Communication n'est pas invisible. Elle maintient un site web public actuel, décrit une offre spécifique d'hébergement et de colocation, détient l'adhésion RIPE, émet un espace IPv4 et IPv6 substantiel via AS42013, apparaît largement dans les collecteurs de routes, et se connecte à PSIX dans une installation nommée de Ramallah. Ce sont des signes significatifs d'une entreprise de réseau régional active.
L'ASN cloud réseau attribué est une autre affaire. AS34008 reste enregistré à la même organisation mais n'a aucune route visible mondialement actuelle et n'a pas émis de route largement observée depuis janvier 2019. Ses anciennes déclarations de politique et préfixes historiques sont des preuves de fonctionnement passé, pas de joignabilité cloud présente. Sur cette surface étroite, la preuve de fonctionnement est négative.
L'AS42013 actif ne peut pas répondre aux plus grandes questions cloud. Les preuves publiques n'établissent pas quelle installation héberge Together Cloud, s'il y a plusieurs sites de production, où résident les sauvegardes, comment le stockage est répliqué, quelle alimentation survit, combien de calcul de rechange existe, quelles heures de support s'appliquent ou comment un client sort. Un réseau actif peut transporter un cloud fragile tout aussi facilement qu'un cloud résilient.
Cela produit trois jugements séparés. La continuité d'entreprise et de réseau pour Together Communication est soutenue. L'exploitation actuelle de AS34008 n'est pas soutenue. La résilience de la plateforme hébergée reste faiblement prouvée. Garder ces jugements séparés évite à la fois le rejet injuste et la confiance injustifiée.
La demande de diligence raisonnable devrait tenir sur une page
Un client potentiel n'a pas besoin de diagrammes sensibles ou d'une visite de chaque baie pour améliorer cette position de preuve. Together peut répondre aux questions centrales dans un calendrier de service compact.
D'abord, nommer la limite d'exploitation: quelle société légale contracte avec le client, quel ASN transporte le service, quelle partie possède les serveurs et quels fournisseurs fournissent l'installation et le transit. Deuxièmement, identifier la ville et le domaine de défaillance pour les copies de production, de réplique et de sauvegarde. Troisièmement, indiquer la capacité installée et de basculement dans des unités pertinentes pour le produit: calcul, mémoire, stockage, puissance de baie et débit réseau.
Quatrièmement, décrire l'alimentation et le refroidissement au niveau de la maintenabilité: alimentations indépendantes, chemins d'onduleur, autonomie du générateur, ravitaillement, réserve de refroidissement et le dernier test de charge. Cinquièmement, décrire la diversité réseau: transporteurs, entrées physiques, dispositifs de bordure, utilisation de PSIX, utilisation normale et capacité après la défaillance d'un chemin. Sixièmement, énoncer la politique de pièces de rechange et de remplacement du matériel pour les hôtes, le stockage, les commutateurs et les optiques.
Septièmement, publier les objectifs de récupération et le résultat de la dernière restauration complète. Huitièmement, nommer les heures de support, les définitions de sévérité et les canaux d'escalade qui restent disponibles pendant une panne réseau. Neuvièmement, fournir le contrat standard couvrant la maintenance, la suspension, les incidents de sécurité et les remèdes. Dixièmement, démontrer l'exportation d'une charge de travail représentative et d'un ensemble de données client.
Aucune de ces demandes ne suppose que Together doive imiter un hyperscaler. Un cloud régional peut être plus petit, plus personnel et plus utile localement. Son avantage devrait être une chaîne plus courte de personnes et d'actifs responsables. Pour rendre cet avantage crédible, la chaîne doit être suffisamment visible pour qu'un client sache ce qui se passe quand le premier maillon cède.
Les preuves actuelles soutiennent une décision de mise en service prudente. Together Communication exploite un vrai réseau et vend publiquement de vraies catégories d'hébergement. Son ASN cloud réseau précis est dormant, et la conception physique derrière le cloud commercial n'est pas divulguée. Les clients devraient traiter le service comme potentiellement utile mais pas encore prouvé pour les charges de travail qui ne peuvent tolérer une défaillance de site, de fournisseur ou de récupération.
Les preuves qui changeraient cette conclusion sont simples: une cartographie de service actuelle, des domaines de défaillance séparés, une capacité de basculement mesurée, des restaurations testées et un chemin de sortie réalisable.